fine grained access control selbstgebastelt?
Thomas Blankschein
siehe Betreff. Ich muss den Usern verschiedene Rechte auf die Datensätze
einiger Tabellen geben. Dabei sind die Zusammenhänge mal recht einfach, mal
sind die Rechte von Informationen in diversen anderen Tabellen abhängig
(konstruiertes Beispiel: Ein Kunde ist einem Vertriebsteam zugeordnet. Ein
User darf nur die Kunden seines Vertriebsteams sehen. Der Chef des Teams
darf auch ändern. usw.).
Oracle bietet ja anscheinend ein entsprechendes Feature (DBMS_RLS-package),
leider nur in der PE und der Enterprise-Version. Wir setzen in der Firma
leider die Standard Edition ein.
Mit entsprechenden Views, bei denen die Kriterien in der WHERE-Klausel
abgebildet werden, kann man zumindest die lesende Seite abbilden. Aber
leider sind die Views je nach Aufbau nicht update-fähig. Muss ich hier jetzt
zwangsläufig mit stored procedures arbeiten?
Mir ist wichtig, dass die Rechteverwaltung direkt in der DB abgebildet wird,
da der Zugriff wahrscheinlich von verschiedenen Frontends aus geschieht.
Thomas
Marc Blum
wrote:
Hallo Thomas,
guck Dir mal INSTEAD OF Trigger an. Damit kannst Du auf einer völlig beliebig
konstruierten View die Schreibzugriffe abfangen und dann mit PL/SQL tun und
lassen, was Du willst. Z.B. das Schreiben von beliebigen Umständen abhängig
durchführen, Die daten in völlig andere Winkel des datenmodells umleiten, eine
komplette Versionierung verbergen (das hat ORACLE in 9 mit dem Workspace Manager
so gemacht).
Alternativ:
<METALINK>
fact: Oracle Server - Standard Edition (DS)
fact: RDBMS - Generic RDBMS
symptom: ORA-00439: feature not enabled: %s
symptom: ORA-00439: feature not enabled: Fine-grained access control
symptom: ORA-06512: at %s, line%s
symptom: ORA-06512: at "SYS.DBMS_RLS", line 308
symptom: DBMS_RLS.ADD_POLICY Fails with ORA-00439 errors
cause: Fine Grained Access, also know as Row Level Security is not available in
the Standard Edition of the Oracle Database.
fix: The Oracle Server Enterprise Edition should be used when applications
require Row Level Security to be available. There are exceptions to this. Oracle
Portal requires Row Level Security. There are occasions where it is necessary to
recreate the Row Level Security (also known as VPD policies) on tables using the
command DBMS_RLS.ADD_POLICY. There should be support for RLS in the Standard
Edition, since Portal is certified and supported with Oracle Server Standard
Edition. RLS can be enabled in the Standard Edition of the Oracle Server with
special event codes in the initialization file : For Oracle8i : event="28119
trace name context forever" For Oracle 9i : event="28131 trace name context
forever" DBMS_RLS.ADD_POLICY will not throw the error message ORA-00439 :
feature not enabled: Fine-grained access control anymore. Do not forget to
remove the special event code after having recreated the Portal VPD Policies. .
</METALINK>
-----------------------
Marc Blum
mailto:ma...@marcblum.de
http://www.marcblum.de
Thomas Blankschein
[INSTEAD OF TRIGGER]
Das ist eine gute Idee, habe ich auch gleich probiert.
Vom Ansatz her ist es das, was ich brauche, nur habe ich
jetzt leider ein kleines Problem:
Meine Insert- und Update-Statements in der Anwendung
verwenden grundsätzlich die RETURNING-Klausel,
um z.B. die per Sequence/Trigger vergebene ID
oder auch Versionsnummern und Namen des Änderungs-Users
zurückzuliefern. Das hat bisher mit direktem Zugriff auf die Tabelle
funktioniert.
Aber kann ich einen INSTEAD OF-Trigger so bauen, dass er
mir Informationen zurückliefert wie ein normales Statement?
Ich befürchte, das geht nicht.
Dann bleibt wohl nur die Variante, die Views Read-Only zu machen
und Insert/Update per Stored Srocedures zu realisieren, die
Daten zurückgeben können.
Danke,
Thomas