Re: tough choices

Serge Rielau wrote:

> OK, let me see if I get this straight.
> Oracle provides a set of procedures which are used to manage "policies"
> against specific tables (or table like objects)/columns. A policy is
> associated with a function.
> the function is user defined and spits out a predicate string which
> Oracle injects into the SQL Statement.
> Whatever smarts (policies) there are are in the user written function.
> Presumable for column level access control some form of CASE expression
> is used to NULL out the data (?)
>
> The promised value add is:
> * in not needing to alter the view, or introduce views for encapsulation
> in the first place.
> * The predicate may be injected or not - depending on whatever the
> policy maker pleases (such as time of day, mood of the boss)
> * There is some level of encapsulation (i.e. the policy package).
>
> The policy maker is responsible to keep up to date with schema changes
> (or the predicates may break) and to ensure proper indexing exists (or
> else the predicates may bring the query to a grinding halt).
>
> Did I miss anything?
> Cheers
> Serge

Only the fact that if someone logs on without going through the approved front-end tool there is no means of bypassing the imposed security.

Your assumption that the policy must be changed to keep up with schema changes is valid but your extention to that being likely to cause a problem is out of proportion to reality. Adding tables, adding columns, dropping columns, etc. will only cause an issue if the objects referred to no longer exist. And if that were the case the code would not compile and or run. Hardly something that would ever make it through development and testing.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)