1. 1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 Specifying & Enforcing Access Constraints These slides are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. For more information on how you may use them, please see http://www.openlineconsult.com/db

2. 2 © Ellis Cohen 2001-2008 Overview of Lecture Access Constraints Relational Access Constraints Enforcing Causal Access Constraints Using Reusable Check Procedures Enforcing Identity-Based Access Constraints Post-Enforcement of Access Constraints Access-Limiting Modification Relational User Access Constraints Relational Informational Access Constraints Enforcing Informational Access Constraints Access Restriction Middle-Tier Identity Data-Tier Identity Access-Limiting Views Trigger-Based Enforcement

3. 3 © Ellis Cohen 2001-2008 Access Constraints

4. 4 © Ellis Cohen 2001-2008 Kinds of System Constraints State Constraints Specifies constraints on the state of the system an invariant property of the database state (something that must always be true and must be able to be checked at ANY ARBITRARY TIME!) Behavior Constraints Specifies constraints on the behavior of the system transition constraints access constraints

5. 5 © Ellis Cohen 2001-2008 Behavior Constraints Transition Constraint Characterizes the results to be produced by specified operations or changes Access Constraint Specifies constraints on what a user or operation is permitted to do

6. 6 © Ellis Cohen 2001-2008 Generalizing Pre-Conditions Many Access Constraints are either a –pre-condition –generalized pre-condition Two ways to generalize pre-conditions Operation-Dependent condition for a group of operations, rather than just a specific one Operation-Independent condition which doesn’t refer to operations at all, but is just based on database/user/environment

7. 7 © Ellis Cohen 2001-2008 Causal & Informational Access Constraints Access Constraints may be Causal restrictions on the kinds of changes or effects that can be caused Informational restrictions of the kinds of data that can be read An Access Constraint specifies restrictions on what a user or operation is permitted to do

8. 8 © Ellis Cohen 2001-2008 Conceptual & Relational Constraints Conceptual Constraint A system constraint, often written informally, in terms of a conceptual model (about entity classes, not tables!) Relational Constraint A system constraint written (often more formally, e.g. using SQL), in terms of a relational model (i.e. tables)

9. 9 © Ellis Cohen 2001-2008 Conceptual & Relational Access Constraints Conceptual Access Constraints Describe restrictions on what users or operations can do, in plain language, in terms of the conceptual model Relational Transition Constraints Describe restrictions, written in a formal SQL-like language, in terms of the relational model

10. 10 © Ellis Cohen 2001-2008 Relational Access Constraints

11. 11 © Ellis Cohen 2001-2008 Example Access Constraint TerminateEmp( :empno ), DestroyDept( :deptno, :reldept ) REQUIRES getDayOfWeek() NOT IN [ 'SAT', SUN' ] Assuming that TerminateEmp & DestroyDept are the only way to terminate an employee The required condition must be true for the employee to be terminated + Conceptual Access Constraint: An employee can only be terminated on a weekday Relational Access Constraint

12. 12 © Ellis Cohen 2001-2008 Relational Access Prevention Constraint TerminateEmp( :empno ), DestroyDept( :deptno, :reldept ) REQUIRES getDayOfWeek() NOT IN [ 'SAT', SUN' ] Constraint Context: Circumstances in which the restriction is to be checked Access Assertion: Formal description of the restriction

13. 13 © Ellis Cohen 2001-2008 Transitionalized Assertions REQUIRES REQUIRES We are mostly interested in writing access constraints for user actions but they can also be written for database actions or procedures in any layer of the implementation Even though a transition assertion is used, we still expect the implementation to determine, as soon as possible (preferably before executing the operation) whether the assertion would be satisfied or not

14. 14 © Ellis Cohen 2001-2008 Example Constraint Contexts A specific user operation TerminateEmp( :empno ) A list of specific user operations TerminateEmp( :empno ), DestroyDept( :deptno, :reldept Any operation/query/action ANY ACTION Any operation/query/action for some role ANY OPERATION BY DeptMgr Operation-based contexts with exceptions ANY ACTION EXCEPT TerminateEmp, DestroyDept ANY OPERATION EXCEPT (ANY QUERY BY Employee) Table-based UPDATE OF job ON Emps

15. 15 © Ellis Cohen 2001-2008 Operation-Independent Access Prevention Constraint An employee can only be terminated on a weekday ANY ACTION REQUIRES (NO Emps& e SATISFIES e IS DELETED) OR (getDayOfWeek() NOT IN [ 'SAT', SUN' ]) The transitionalized assertion describes the required result if the operation would be executed But we still expect the implementation to determine, as soon as possible (preferably before executing the operation) whether the assertion would be satisfied or not

16. 16 © Ellis Cohen 2001-2008 Enforcing Causal Access Constraints

17. 17 © Ellis Cohen 2001-2008 Enforcing Access Constraints Access constraints are always enforced by rejection, either by: Application Enforcement: Enforce constraints through code implemented in user operations (in the middle-tier) or stored DB operations (in the data-tier) Database Enforcement: Use built-in database features to automatically enforce access constraints in the data-tier (triggers, views, USER identity, privileges & roles) Access constraints that are not enforced will inevitably compromise the database

18. 18 © Ellis Cohen 2001-2008 Application Enforcement of Operation-Independent Access Constraints 1.Determine which operations need to have code to check the access constraint (e.g. TerminateEmp and DestroyDept) 2.Add code to each such operation (e.g. a call to a reusable procedure, especially if there is more than one operation) to enforce it. An employee can only be terminated on a weekday

19. 19 © Ellis Cohen 2001-2008 Using Conditional Code BEGIN IF getDayOfWeek() NOT IN [ 'SAT', 'SUN' ] THEN DELETE Emps WHERE empno = :empno; END IF; EXCEPTION WHEN OTHERS THEN doerr(); END; TerminateEmp( :empno ) This code works, but better code can be written. What's wrong with this code? Original Base Operation Code Conditionalized Base Operation Code

20. 20 © Ellis Cohen 2001-2008 Problems with the Code 1.If the access constraint is violated, no error message is shown 2.If there is no employee :empno, no error message is shown 3.Uses white box enforcement: The base operation code is intertwined with the business rule (the access check), making maintenance harder 4.There may be many operations that need to check the day of the week, but the code as written is not very reusable

21. 21 © Ellis Cohen 2001-2008 Application-Based Enforcement White Box Enforcement –Look at the code of each relevant operation, and modify it in the best possible way to enforce the constraint Black Box Enforcement –Leave the existing operation code alone (except to place information in local variables from modified tuples using RETURNING clauses) –Add code after the base modification code of each relevant operation to enforce the constraint –May also need to add code before the existing code to handle setup for the after code –For access constraints, it is generally possible to place all (or most) of the enforcement code before the base modification code

22. 22 © Ellis Cohen 2001-2008 Using Inline Exceptions DECLARE knt int; BEGIN IF getDayOfWeek() IN [ 'SAT', SUN' ] THEN RAISE_APPLICATION_ERROR( -20086, 'Operation only allowed on weekday' ); END IF; SELECT count(*) INTO knt FROM Emps WHERE empno = :empno; IF knt = 0 THEN RAISE_APPLICATION_ERROR( -20033, 'No such employee' ); END IF; DELETE Emps WHERE empno = :empno; EXCEPTION WHEN OTHERS THEN doerr(); END; TerminateEmp( :empno ) Original Base Operation Code Uses Black Box enforcement; all enforcement code added before or after original base code Access Constraint Enforcement Code

23. 23 © Ellis Cohen 2001-2008 Using SQL%ROWCOUNT BEGIN IF getDayOfWeek() IN [ 'SAT', SUN' ] THEN RAISE_APPLICATION_ERROR( -20086, 'Operation only allowed on weekday' ); END IF; DELETE Emps WHERE empno = :empno; IF SQL%ROWCOUNT = 0 THEN RAISE_APPLICATION_ERROR( -20033, 'No such employee' ) END IF; EXCEPTION WHEN OTHERS THEN doerr(); END; TerminateEmp( :empno ) Original Base Operation Code SQL%ROWCOUNT is the # of tuples that were modifed in the previous SQL operation

24. 24 © Ellis Cohen 2001-2008 Enforcement Approaches Conditional Code (--) –White box implementation limits reusability & maintainability Inline Exceptions (-) –More maintainable black box implementation

25. 25 © Ellis Cohen 2001-2008 Using Reusable Check Procedures

26. 26 © Ellis Cohen 2001-2008 Using Reusable Check Procedures BEGIN CheckWeekday(); DELETE Emps WHERE empno = :empno; CheckResults( -20033, 'No such employee' ); EXCEPTION WHEN OTHERS THEN doerr(); END; TerminateEmp( :empno ) Original Base Operation Code Uses Black Box enforcement and all enforcement code before or after original base code is placed in reusable check procedures

27. 27 © Ellis Cohen 2001-2008 CheckResults Implementation PROCEDURE CheckResults( errno, int errmsg varchar ) IS BEGIN IF SQL%ROWCOUNT = 0 THEN RAISE_APPLICATION_ERROR( errno, errmrg ); END IF; END;

28. 28 © Ellis Cohen 2001-2008 CheckWeekday Implementation PROCEDURE CheckWeekday IS BEGIN IF getDayOfWeek() IN [ 'SAT', SUN' ] THEN RAISE_APPLICATION_ERROR( -20086, 'Operation only allowed on weekday' ); END IF; END; FUNCTION getDayOfWeek RETURN varchar IS today varchar(3) BEGIN SELECT to_char(sysdate,'DY') INTO today FROM dual; RETURN today; END;

29. 29 © Ellis Cohen 2001-2008 Enforcement Approaches Conditional Code (--) –White box implementation limits reusability & maintainability Inline Exceptions (-) –More maintainable black box implementation Reusable Check Procedures –Clean, reusable & maintainable black box implementation

30. 30 © Ellis Cohen 2001-2008 Enforcing Identity-Based Access Constraints

31. 31 © Ellis Cohen 2001-2008 Types of Access Constraints Status Access Constraints –based on the current status of the database or the environment, but not based on the role or identity of the user (or client) –e.g. An employee can only be terminated on a weekday Role-Based User Access Constraints –based strictly on the current user/client's role Identity-Based User Access Constraints –based on (information tied to the) identity of the current user (or client)

32. 32 © Ellis Cohen 2001-2008 Identity-Based User Access Constraint BEGIN UPDATE Emps SET sal = :sal WHERE empno = :empno; EXCEPTION WHEN OTHERS THEN doerr(); END; ChangeSal( :empno, :sal ) + Access Constraint: Only an employee's manager can change their salary

33. 33 © Ellis Cohen 2001-2008 Using Conditional Code DECLARE mgrno int; BEGIN SELECT mgr INTO mgrno FROM Emps WHERE empno = :empno; IF (mgrno = :curuser) THEN UPDATE Emps SET sal = :sal WHERE empno = :empno; END IF; EXCEPTION WHEN OTHERS THEN doerr(); END; ChangeSal( :empno, :sal ) What's wrong with this code? Conditionalized Base Operation Code

34. 34 © Ellis Cohen 2001-2008 Problems with the Code 1.If there is no employee :empno, the resulting error message will be obscure 2.If the employee's manager is not the current user, or the employee doesn't have a manager, there will be no error message at all 3.There may be many operations that need to check whether :empno's manager is the current user, but the code as written is not very reusable 4.Uses white box enforcement Rewrite the code to fix these problems, using Inline Exceptions

35. 35 © Ellis Cohen 2001-2008 Using Inline Exceptions DECLARE mgrno int; BEGIN BEGIN SELECT mgr INTO mgrno FROM Emps WHERE empno = :empno; EXCEPTION WHEN OTHERS THEN RAISE_APPLICATION_ERROR( -20043, 'No such employee' ); END; IF (mgrno = :curuser) THEN NULL; ELSE RAISE_APPLICATION_ERROR( -20044, 'You are not the employee's manager' ) END IF; UPDATE Emps SET sal = :sal WHERE empno = :empno; EXCEPTION WHEN OTHERS THEN doerr(); END; ChangeSal( :empno, :sal ) Inline Exception Code Original Base Code: Using Black Box Enforcement

36. 36 © Ellis Cohen 2001-2008 Combining Error Messages DECLARE mgrno int; BEGIN BEGIN SELECT mgr INTO mgrno FROM Emps WHERE empno = :empno; EXCEPTION WHEN OTHERS THEN NULL; END; IF (mgrno = :curuser) THEN NULL; ELSE RAISE_APPLICATION_ERROR( -20044, 'You are not the employee's manager' ) END IF; UPDATE Emps SET sal = :sal WHERE empno = :empno; EXCEPTION WHEN OTHERS THEN doerr(); END; ChangeSal( :empno, :sal ) Leaves mgrno NULL, so the following statement produces an error Inline Exception Code

37. 37 © Ellis Cohen 2001-2008 SELECT-Only Enforcement DECLARE knt int; BEGIN SELECT count(*) INTO knt FROM Emps WHERE empno = :empno AND mgr = :curuser; IF (knt = 0) THEN RAISE_APPLICATION_ERROR( -20044, 'You are not the employee's manager' ); END IF; UPDATE Emps SET sal = :sal WHERE empno = :empno; EXCEPTION WHEN OTHERS THEN doerr(); END; ChangeSal( :empno, :sal ) Notice how all the checking is moved into a single SELECT statement The code that does checking is often reused; so it can be useful to make it a stored procedure. Do that!

38. 38 © Ellis Cohen 2001-2008 Incorrect Reusable Check Procedure BEGIN CheckManage( :empno ); UPDATE Emps SET sal = :sal WHERE empno = :empno; EXCEPTION WHEN OTHERS THEN doerr(); END; ChangeSal( :empno, :sal ) PROCEDURE CheckManage( anEmpno int ) IS knt int; BEGIN SELECT count(*) INTO knt FROM Emps WHERE empno = anEmpno AND mgr = :curuser; IF (knt = 0) THEN RAISE_APPLICATION_ERROR( -20044, 'You are not the employee's manager' ); END IF; END; ILLEGAL CODE! Can't access session variables from stored procedures. How do you fix it?

39. 39 © Ellis Cohen 2001-2008 Correct Reusable Check Procedure BEGIN CheckManage( :curuser, :empno ); UPDATE Emps SET sal = :sal WHERE empno = :empno; EXCEPTION WHEN OTHERS THEN doerr(); END; ChangeSal( :empno, :sal ) PROCEDURE CheckManage( curusr int, anEmpno int ) IS knt int; BEGIN SELECT count(*) INTO knt FROM Emps WHERE empno = anEmpno AND mgr = curusr; IF (knt = 0) THEN RAISE_APPLICATION_ERROR( -20044, 'You are not the employee's manager' ); END IF; END; Procedures are stored in the data-tier, so they can't access session variables. Only anonymous blocks can! Or, maintain curuser in the data tier!

40. 40 © Ellis Cohen 2001-2008 Checking Exercise Suppose that an employee's salary could only be changed by the dept manager of the employee's department. Rewrite CheckManage (preferably using a SELECT-only approach, although this requires a self-join or subquery)

41. 41 © Ellis Cohen 2001-2008 Using a Join PROCEDURE CheckManage( curusr int, anEmpno int ) IS knt int; BEGIN SELECT count(*) INTO knt FROM Emps e1, Emps e2 WHERE e1.empno = curusr AND e1.job = 'DEPTMGR' AND e1.deptno = e2.deptno AND e2.empno = anEmpno; IF (knt = 0) THEN RAISE_APPLICATION_ERROR( -20045, 'You are not the employee's dept manager' ); END IF; END;

42. 42 © Ellis Cohen 2001-2008 Using a Subquery PROCEDURE CheckManage( curusr int, anEmpno int ) IS knt int; BEGIN SELECT count(*) INTO knt FROM Emps WHERE empno = curusr AND job = 'DEPTMGR' AND deptno = (SELECT deptno FROM Emps WHERE empno = anEmpno); IF (knt = 0) THEN RAISE_APPLICATION_ERROR( -20045, 'You are not the employee's dept manager' ); END IF; END; The SELECT could also be written as SELECT count(*) INTO knt FROM Emps WHERE empno = anEmpno AND deptno = (SELECT deptno FROM Emps WHERE empno = curusr AND job = 'DEPTMGR')

43. 43 © Ellis Cohen 2001-2008 Post-Enforcement of Access Constraints

44. 44 © Ellis Cohen 2001-2008 Post-Enforcement For access constraints, it is generally possible to place all (or most) of the enforcement code before the base modification code. However, in some cases, it is simpler to place the enforcement code after the base modification code –(rare) Easier to check the constraint based on the state after the modification has been done. [Remember rejection will cause the modification to be rolled back] –Information needed for checking can be obtained from a RETURNING clause in the base modification code.

45. 45 © Ellis Cohen 2001-2008 Identity-Based User Access Constraint BEGIN UPDATE Emps SET sal = :sal WHERE empno = :empno; EXCEPTION WHEN OTHERS THEN doerr(); END; ChangeSal( :empno, :sal ) + Access Constraint: Only an employee's manager can change their salary

46. 46 © Ellis Cohen 2001-2008 Using Post-Enforcement DECLARE mgrno int; BEGIN UPDATE Emps SET sal = :sal WHERE empno = :empno RETURNING mgr INTO mgrno; IF (mgrno != :curuser) THEN RAISE_APPLICATION_ERROR( -20044, 'You are not the employee's manager' ); END IF; EXCEPTION WHEN OTHERS THEN doerr(); END; ChangeSal( :empno, :sal ) Access constraint enforced after the base operation code. Could be turned into a reusable check procedure. Base Operation Code with RETURNING clause

47. 47 © Ellis Cohen 2001-2008 Access-Limiting Modification

48. 48 © Ellis Cohen 2001-2008 Using Access-Limiting Modification BEGIN DELETE Emps WHERE empno = :empno AND getDayOfWeek() NOT IN [ 'SAT', SUN' ]; CheckResults( -20033, 'Not legal' ); EXCEPTION WHEN OTHERS THEN doerr(); END; TerminateEmp( :empno ) Access-limiting modification adds access checking as WHERE conditions to operation base code. An employee can only be terminated on a weekday How could the error message be better? Access- limiting modification

49. 49 © Ellis Cohen 2001-2008 Access-Limiting Modification It is possible to add access-checking conditions to modification operations (INSERT, UPDATE, DELETE, MERGE). This can dramatically simplify code, although –it does meld together the base code & the access-checking code –uses white box vs black box enforcement

50. 50 © Ellis Cohen 2001-2008 Using Access-Limiting Modification BEGIN UPDATE Emps SET sal = :sal WHERE empno = :empno AND mgr = :curuser; CheckResults( -20044, 'You are not the employee's manager' ); EXCEPTION WHEN OTHERS THEN doerr(); END; ChangeSal( :empno, :sal ) Access-limiting modification Only an employee's manager can change their salary Suppose an employee's salary could only be changed by the dept mgr of their department?

51. 51 © Ellis Cohen 2001-2008 Access-Limiting Modification BEGIN UPDATE Emps SET sal = :sal WHERE empno = :empno AND deptno = (SELECT deptno FROM Emps WHERE empno = :curuser AND job = 'DEPTMGR'); CheckResults( -20044, 'You are not the employee's dept manager' ); EXCEPTION WHEN OTHERS THEN doerr(); END; ChangeSal( :empno, :sal ) Only the dept manager of an employee's dept can change their salary Access-limiting modification

52. 52 © Ellis Cohen 2001-2008 Enforcement Approaches Conditional Code (--) –White box implementation limits reusability & maintainability Inline Exceptions (-) –More maintainable black box implementation Reusable Check Procedures –Clean, reusable & maintainable black box implementation Access-Limiting Modifications –White box implementation, but can result in significantly cleaner code with better performance

53. 53 © Ellis Cohen 2001-2008 UI Constraint Enforcement Why do we even need to check the access constraint? Shouldn’t a real UI be constructed so that for ChangeSal, it only lets the user select from the list of employees that the user manages? ChangeSal( :empno, :sal )

54. 54 © Ellis Cohen 2001-2008 Bypassing UI Enforcement 1.UI presentation code may have errors 2.With a web-based application, clever users can arrange to have an arbitrary empno value passed back to the middle- tier anyway 3.Intruders can intercept and modify communication between the browser and the middle-tier 4.Middle-tiers are increasingly likely to have web service interfaces, in which there is no UI checking

55. 55 © Ellis Cohen 2001-2008 Relational User Access Constraints

56. 56 © Ellis Cohen 2001-2008 User Access Constraint Only a logged in user can change the visibility of their address ChangeMyAddressVisibility( :visible ) REQUIRES % USER IS NOT NULL % USER identifies the current user of the system The content and data representation of % USER is application-specific A NULL value for % USER always implies that there is no logged in user % USER is not part of standard SQL or PL/SQL It is only used in writing assertions

57. 57 © Ellis Cohen 2001-2008 Who is %USER? Database User? The name the user/client used to connect to the database (e.g. SCOTT or EmpDB) Application User? The id that a user/client used to login and identify themselves to an application (e.g. via invoking a Login user action) In writing assertions, %USER is the application user! Also can use %ROLE but only when user's role is static after login

58. 58 © Ellis Cohen 2001-2008 Database vs. Application User SQL> connect EmpDB/OK EmpDB> @&u/Login 24792 buzzray EmpDB> @&u/ShowSals Indicates that we are in SQL*Plus connected as Database User EmpDB. The user runs a login script that logs him into the Employee DB Application as Application User 27942, password 'buzzray' Application User 27942 runs a ShowsSals script which shows user salaries

59. 59 © Ellis Cohen 2001-2008 Relational User Access Constraint ChangeSal( :empno, :sal ) REQUIRES % USER = (SELECT mgr FROM Emps WHERE empno = :empno) Assumes that if an employee is logged in, % USER is their employee number + Access Constraint: Only an employee's manager can change their salary

60. 60 © Ellis Cohen 2001-2008 Operation-Independent Relational Access Constraint ANY ACTION REQUIRES EACH Emps& e WHERE e IS MODIFIED AT sal SATISFIES e.mgr' = %USER + Access Constraint: Only an employee's manager can change their salary Uses the MODIFIED predicate, defined in earlier slides on Transition Assertions

61. 61 © Ellis Cohen 2001-2008 Relational Informational Access Constraints

62. 62 © Ellis Cohen 2001-2008 Informational Access Restriction Informational Access Constraints that restrict access are often generalizations of Output-Related Post-Conditions (i.e. conditions on the output of an operation)

63. 63 © Ellis Cohen 2001-2008 Output-Related Post-Condition SELECT ename, sal FROM Emps WHERE empno = :empno ShowSal( :empno ) + Output-Related Post-Condition: Can only display information about the current user or an employee that user manages Generalize this to an access constraint

64. 64 © Ellis Cohen 2001-2008 Restricted Access Constraint An employee can only access (or see) their own salary, and the salary of employees they manage + Output-Related Post-Condition: Can only display information about the current user or an employee that user manages SELECT ename, sal FROM Emps WHERE empno = :empno ShowSal( :empno )

65. 65 © Ellis Cohen 2001-2008 Specifying Informational Access Constraints An employee can only see their own salary and the salaries of employees they manage ANY OPERATION REQUIRES EACH Emps& e WHERE e IS ACCESSED AT sal SATISFIES e.empno' = %USER OR e.mgr' = %USER

66. 66 © Ellis Cohen 2001-2008 Predefined Access Predicates x IS ACCESSED AT attr Attribute attr of tuple x is accessed by the operation x IS ACCESSED AT a1, …, an (x IS ACCESSED AT a1) OR … (x IS ACCESSED AT an) x IS ACCESSED EXCEPT AT a1, …, an means that some of x's attributes (other than a1, …, an) are updated Writing the access assertion requires some way of describing which tuples and attributes are accessed

67. 67 © Ellis Cohen 2001-2008 Enforcing Informational Access Constraints

68. 68 © Ellis Cohen 2001-2008 Informational Access Constraint + An employee's salary can only be accessed by the employee or by their direct manager SELECT ename, sal FROM Emps WHERE empno = :empno ShowSal( :empno )

69. 69 © Ellis Cohen 2001-2008 Using Reusable Check Procedure BEGIN CheckSelfManage( :curuser, :empno ); … code to display the name & salary … EXCEPTION WHEN OTHERS THEN doerr(); END; PROCEDURE CheckSelfManage( curusr int, anEmpno int ) IS knt int; BEGIN IF anEmpno != curuser THEN SELECT count(*) INTO knt FROM Emps WHERE empno = anEmpno AND mgr = curusr; IF (knt = 0) THEN RAISE_APPLICATION_ERROR( -20044, 'You are not the employee or their manager' ); END IF; END; ShowSal( :empno ) Write the code

70. 70 © Ellis Cohen 2001-2008 Code to Display Name & Salary BEGIN CheckSelfManage( :curuser, :empno ); FOR rec IN (SELECT ename, sal FROM Emps WHERE empno = :empno) LOOP pl( rec.ename || ': ' || rec.sal ); END LOOP; EXCEPTION WHEN OTHERS THEN doerr(); END; ShowSal( :empno ) BEGIN CheckSelfManage( :curuser, :empno ); SELECT ename, sal FROM Emps WHERE empno = :empno; EXCEPTION WHEN OTHERS THEN doerr(); END; ILLEGAL CODE! Can't use a raw SELECT as a PL/SQL statement

71. 71 © Ellis Cohen 2001-2008 Using Access-Limiting Query SELECT empno, ename, sal FROM Emps WHERE empno = :empno AND (empno = :curuser OR mgr = :curuser) An employee can only see their own salary and the salaries of employees they manage Can we raise an exception if no user is logged in? ShowSal( :empno ) PRO: Lets SQL*Plus handle the formatting BUT: If the constraint is not satisfied, it doesn’t show any results, and doesn't print an error

72. 72 © Ellis Cohen 2001-2008 Access-Limiting Query with Exception Function SELECT empno, ename, sal FROM Emps WHERE empno = :empno AND TestSelfManage( :curuser, empno, mgr ) = 1 ShowSal( :empno ) PROCEDURE TestSelfManage( curusr int, empno int, mgr int ) RETURN int IS BEGIN IF empno != curuser AND mgr != curusr THEN RAISE_APPLICATION_ERROR( -20044, 'You are not the employee or their manager' ); END IF; RETURN 1; END; But no way to display it via doerr

73. 73 © Ellis Cohen 2001-2008 Enforcement Approaches Conditional Code (--) –Limits reusability & maintainability Inline Exceptions (-) –More maintainable Reusable Check Procedures –Clean, reusable & maintainable Access-Limiting Queries & Modifications –White box implementation, but can result in significantly cleaner code with better performance

74. 74 © Ellis Cohen 2001-2008 Access Restriction

75. 75 © Ellis Cohen 2001-2008 Access Restriction Access constraints constrain behavior in two ways Prevention: the operation is not permitted to execute (or has no effect or results if it does) generalizations of pre-conditions Restriction: the operations is permitted to execute, but its behavior is restricted Causal: limits to data it can modify Informational: limits access to the data it can read or output

76. 76 © Ellis Cohen 2001-2008 Specifying Causal Access Restrictions ANY ACTION REQUIRES EACH Emps& e WHERE e IS MODIFIED AT sal SATISFIES e.mgr' = %USER + Access Constraint: Only an employee's manager can change their salary Causal Access Restrictions can either use REQUIRES or RESULTS IN

77. 77 © Ellis Cohen 2001-2008 Causal Access Restrictions BEGIN UPDATE Emps SET sal = sal * :vary; EXCEPTION WHEN OTHERS THEN doerr(); END; RaiseSal( :vary ) How would you enforce this without rejecting the entire operation? + Access Constraint: Only an employee's manager can change their salary

78. 78 © Ellis Cohen 2001-2008 Enforcing Causal Access Restrictions BEGIN UPDATE Emps SET sal = sal * :vary WHERE mgr = :curuser; EXCEPTION WHEN OTHERS THEN doerr(); END; RaiseSal( :vary ) Use white-box enforcement: access-limiting modification + Access Constraint: Only an employee's manager can change their salary

79. 79 © Ellis Cohen 2001-2008 Specifying Informational Access Restrictions An employee can only see their own salary and the salaries of employees they manage ANY OPERATION REQUIRES EACH Emps& e WHERE e IS ACCESSED AT sal SATISFIES e.empno' = %USER OR e.mgr' = %USER

80. 80 © Ellis Cohen 2001-2008 Informational Access Restrictions SELECT empno, ename, sal FROM Emps; ShowSals + An employee's salary can only be accessed by the employee or by their direct manager How would you enforce this without rejecting the entire operation?

81. 81 © Ellis Cohen 2001-2008 Using Access-Limiting Query SELECT empno, ename, sal FROM Emps WHERE empno = :curuser OR mgr = :curuser An employee can only see their own salary and the salaries of employees they manage Can we raise an exception if no user is logged in? ShowSals PRO: Lets SQL*Plus handle the formatting BUT: If the user is not logged in, it doesn’t show any results, and doesn't print an error

82. 82 © Ellis Cohen 2001-2008 Access-Limited Query with Exception Function SELECT empno, ename, sal FROM Emps WHERE LegalUser( :curuser ) = 1 AND (empno = :curuser OR mgr = :curuser ) ShowSals FUNCTION LegalUser( curusr int ) RETURN int IS BEGIN IF ( curusr IS NULL) THEN RAISE_APPLICATION_ERROR( -20077, 'Not Logged In' ); END IF; RETURN 1; END;

83. 83 © Ellis Cohen 2001-2008 Access-Limiting Query w Initial Access Check BEGIN CheckUser( :curuser ); FOR rec IN (SELECT empno, ename, sal FROM Emps WHERE empno = :curuser OR mgr = :curuser) LOOP pl( rec.empno || ' ' || rec.ename || ' ' || rec.sal ); END LOOP; END; ShowSals PROCEDURE CheckUser( curusr int ) IS BEGIN IF ( curusr IS NULL) THEN RAISE_APPLICATION_ERROR( -20077, 'Not Logged In' ); END IF; END;

84. 84 © Ellis Cohen 2001-2008 Access-Limiting Query For Loop Final Error Message DECLARE knt int := 0; BEGIN FOR rec IN (SELECT empno, ename, sal FROM Emps WHERE empno = :curuser OR mgr = :curuser) LOOP pl( rec.empno || ' ' || rec.ename || ' ' || rec.sal ); knt := knt + 1; END LOOP; condraise( knt = 0, -20001, 'Not Logged In' ); END; ShowSals Note: SQL%ROWCOUNT doesn’t work after a query-for loop

85. 85 © Ellis Cohen 2001-2008 Informational Access Restrictions & Output-Related Post Conditions Information Access Restrictions often generalize Output-Related Post-Conditions Output-Related Post-Conditions characterize resulting properties of the operation output Transition Constraints and State-Related Post-Conditions are described in terms of the state of tables We can use the same approach to describe Output-Related Post-Condition if we treat the OUTPUT as equivalent to one or more tables

86. 86 © Ellis Cohen 2001-2008 Relational Specification of Output-Related Post-Condition ShowSals OUTPUT EmpSals( empno, ename, sal ) RESULTS IN EACH EmpSals& es SATISFIES SOME Emps& e SATISFIES es.empno@ = e.empno' AND es.sal@ = e.sal' AND (e.empno' = %USER OR e.mgr' = %USER)

87. 87 © Ellis Cohen 2001-2008 Middle-Tier Identity

88. 88 © Ellis Cohen 2001-2008 Middle-Tier Identity In Middle-Tier Identity, the identity of the user is stored in a session variable e.g. :curuser maintained in the middle tier. Possibly, the user's role is maintained as well, e.g. in :currole

89. 89 © Ellis Cohen 2001-2008 Defining Login BEGIN SELECT userid, role INTO :curuser, :currole FROM AuthUsers WHERE userid = :userid AND pwd = :passwd; EXCEPTION WHEN OTHERS THEN RAISE_APPLICATION_ERROR( …, ' Illegal Userid or Password' ); END; EXCEPTION WHEN OTHERS THEN doerr(); END; Login( :userid, :passwd ) User operation name & parameters

90. 90 © Ellis Cohen 2001-2008 Script-Based Login Implementation BEGIN SELECT userid, role INTO :curuser, :currole FROM AuthUsers WHERE userid = &1 AND pwd = &2; EXCEPTION WHEN OTHERS THEN RAISE_APPLICATION_ERROR( …, ' Illegal Userid or Password' ); END; EXCEPTION WHEN OTHERS THEN doerr(); END; Login( :userid, :passwd ) &1 – :userid &2 – :passwd

91. 91 © Ellis Cohen 2001-2008 Separating Authentication We could just keep an employee's password & role in the Emps table But, it’s better to keep them in a separate table – e.g. AuthUsers –Provides better security –Makes it easy to switch to handling authentication in a separate service –Makes it easier to handle case where users other than employees are allowed to log into system

92. 92 © Ellis Cohen 2001-2008 Specifying Role-Based Access Constraints TerminateEmp( :empno ) REQUIRES % ROLE = 'President' Assumes that if an employee is logged in, % ROLE is their role + Access Constraint: Only the president can terminate an employee

93. 93 © Ellis Cohen 2001-2008 Enforcing Role-Based Access Constraints + Access Constraint: Only the president can terminate an employee BEGIN DELETE Emps WHERE empno = :empno AND :currole = 'President'; CheckResults( -20033, 'Cannot delete employee' ); EXCEPTION WHEN OTHERS THEN doerr(); END; TerminateEmp( :empno ) Uses Access-Limited Modification. A Reusable Check Procedure implementation would allow more precise error messages

94. 94 © Ellis Cohen 2001-2008 Determining Role Maintain each user's role – e.g. in the AuthUser's table Determine the role based on the user's id. For example, userid from 1000-1999 have one role, userids from 2000-2999 have a different role. Simple, but a problem if user's roles can change Calculate the user's role based on other user properties that may dynamically change, e.g. an employee's job, etc. (instead of maintaining :currole)

95. 95 © Ellis Cohen 2001-2008 Using Calculated Roles + Access Constraint: Only the president can terminate an employee DECLARE currole varchar(20) := GetRole( :curuser ); BEGIN DELETE Emps WHERE empno = :empno AND currole = 'President'; CheckResults( -20033, 'Cannot delete employee' ); EXCEPTION WHEN OTHERS THEN doerr(); END; TerminateEmp( :empno ) Uses Access-Limited Modification. A Reusable Check Procedure implementation would allow more precise error messages

96. 96 © Ellis Cohen 2001-2008 Calculated Role CREATE OR REPLACE FUNCTION GetRole( anEmpno int ) RETURN varchar IS theJob varchar(30); theRole varchar(30); knt int; BEGIN SELECT job INTO theJob FROM Emps WHERE empno = anEmpno; CASE theJob WHEN 'PRESIDENT' THEN theRole := 'President'; WHEN 'DEPTMGR' THEN theRole := 'DeptMgr'; ELSE SELECT count(*) INTO knt FROM Emps WHERE mgr = anEmpno; IF knt > 0 THEN theRole := 'Manager'; ELSIF theJob IS NOT NULL THEN theRole := 'Employee'; END IF; END CASE; RETURN theRole; EXCEPTION WHEN OTHERS THEN RETURN NULL; END;

97. 97 © Ellis Cohen 2001-2008 Mutating Table Errors + Access Constraint: Only the president can terminate an employee BEGIN DELETE Emps WHERE empno = :empno AND GetRole( :curuser ) = 'President'; CheckResults( -20033, 'Cannot delete employee' ); EXCEPTION WHEN OTHERS THEN doerr(); END; TerminateEmp( :empno ) Inefficient and causes a Mutating Table error, since GetRole may do a query on Emps in the midst of another query on Emps

98. 98 © Ellis Cohen 2001-2008 Data-Tier Identity

99. 99 © Ellis Cohen 2001-2008 Middle-Tier Identity Problems Maintaining user identity using a middle-tier session variable (e.g. :curuser) is problematic –Stored procedures can only access middle-tier variables if they are passed as parameters –Views cannot access middle-tier variables (though there are workarounds) –Triggers cannot access middle- tier variables (no good workarounds)

100. 100 © Ellis Cohen 2001-2008 Authentication with Middle-Tier Identity EmpDB DB App on Web/App Server :curuser 7782 App User 7782 Database authenticates the application connecting as EmpDB The application can then access all of EmpDB's objects Application authenticates the user logging in as 7782

101. 101 © Ellis Cohen 2001-2008 Approaches to User Identity Middle-Tier Identity –Maintain user identity by middle-tier session variables (e.g. :curuser) Data-Tier Identity –Maintain user identity in the data-tier, e.g. storing the identity in a package variable Database Identity –Users are identified by their database connection id (e.g. SCOTT) (discussed in later slides)

102. 102 © Ellis Cohen 2001-2008 Advantages of Data Tier Identity Allows views & triggers to be written which are based on the identity of the current user. Allows procedures & functions to be dependent on the current user, without having to pass it as a parameter. Especially important for –functions called from views –functions & procedures called from triggers

103. 103 © Ellis Cohen 2001-2008 Maintaining Data-Tier Identity Suppose our application defines an AuthPkg to register and login users, and to keep track of the current user in each session, with operations: PROCEDURE Register( aUser, aPwd, aRole ) PROCEDURE Login( usr, pwd, theRole ) PROCEDURE Logout FUNCTION GetUser RETURN int -- returns logged in user (or NULL) FUNCTION GetRole RETURN varchar -- returns role of logged in user (or NULL) OUT parameter CAUTION: You might not want to retain the role in the database if it could change depending upon other changes in database state (e.g. the user's job)

104. 104 © Ellis Cohen 2001-2008 Authentication with Data-Tier Identity EmpDB curusr 7782 DB App on Web/App Server App User 7782 Database authenticates the application connecting as EmpDB The application can then access all of EmpDB's objects Application authenticates the user logging in as 7782 (with the help of EmpDB's AuthPkg)

105. 105 © Ellis Cohen 2001-2008 Middle-Tier vs Data-Tier Identity Presentation Tier Data TierMiddle Tier EmpDB curusr 7782 Web Browser DB App on Web/App Server App User 7782 EmpDB DB App on Web/App Server :curuser 7782 App User 7782 7782 could still be cached in the middle tier

106. 106 © Ellis Cohen 2001-2008 AuthPkg Body CREATE TABLE AuthUsers( userid int PRIMARY KEY, passwd varchar(128), role varchar(30) ); CREATE PACKAGE BODY AuthPkg AS curuser int; currole varchar(20); PROCEDURE Login( usr int, pwd varchar, theRole OUT char ) IS BEGIN SELECT userid, role INTO curuser, currole FROM AuthUsers WHERE userid = usr AND passwd = pwd; theRole := currole; EXCEPTION WHEN OTHERS THEN RAISE_APPLICATON_ERROR( -20099, 'Illegal Login' ); END; FUNCTION GetUser RETURNS int IS BEGIN RETURN curuser; END; FUNCTION GetRole RETURNS int IS BEGIN RETURN currole; END; …

107. 107 © Ellis Cohen 2001-2008 AuthPkg Body Continued PROCEDURE Register( aUser int, aPwd varchar, aRole varchar ) IS BEGIN INSERT INTO AuthUsers VALUES( aUser, aPwd, aRole ); END; PROCEDURE Logout IS BEGIN curuser := NULL; currole := NULL; END; … END AuthPkg; Each DB session (i.e. connection) has its own instance of package variables. So curuser & currole have values specific to the connected DB session

108. 108 © Ellis Cohen 2001-2008 Using AuthPkg SELECT empno, ename, sal FROM Emps WHERE empno = AuthPkg.GetUser OR mgr = AuthPkg.GetUser ShowSals DECLARE theRole varchar(30); BEGIN AuthPkg.Login( :userid, :pwd, theRole ); pl( 'Logged in with role ' || theRole ); EXCEPTION WHEN OTHERS THEN doerr(); END; Login( :empno, :pwd ) Shows salaries for current user and employees they manage This could also cache the userid and role in the middle tier

109. 109 © Ellis Cohen 2001-2008 Connection Issues Storing user-session data in the data tier (where is maintained on a per-connection basis) implies that the middle tier maintains a separate connection with the database for every user- session. However typically there are a limited # of connections betweens a Web/App server & the DB server So either Use DB virtual connections (allows coding as if there were a separate connection for each DB user) Switch the current user as a prelude to each user operation (though this requires auto-commit)

110. 110 © Ellis Cohen 2001-2008 Registering Users Users and their passwords can be registered separately, or as part of the appropriate operation BEGIN INSERT INTO Emps( empno, ename, sal, job, mgr, deptno ) VALUES (:empno, :ename, :sal, :job, :mgr, :deptno ); -- Register them AuthPkg.Register( :empno, :pwd, GetRole(:job) ) END; AddEmp( :empno, :pwd, :ename, :sal, :job, :mgr, :deptno ) Only because role is calculated based on the employee's job (otherwise provide it as a parameter) In this case, it would actually be better to calculate a user's role when they login or when it is needed Similarly, TerminateEmp should call AuthPkg.Unregister Note: instead of providing a password, a default one can be initially assigned

111. 111 © Ellis Cohen 2001-2008 Access-Limiting Views

112. 112 © Ellis Cohen 2001-2008 Access-Limiting View for Query CREATE VIEW EmpMgrView IS SELECT * FROM Emps WHERE empno = AuthPkg.GetUser OR mgr = AuthPkg.GetUser Hides the access constraint enforcement in the view. Separates the operation from the constraint SELECT empno, ename, sal FROM EmpMgrView ShowSals

113. 113 © Ellis Cohen 2001-2008 Using Access-Limiting Modification BEGIN UPDATE Emps SET sal = :sal WHERE empno = :empno AND mgr = :curuser; CheckResults( -20044, 'You are not the employee's manager' ); EXCEPTION WHEN OTHERS THEN doerr(); END; ChangeSal( :empno, :sal ) Access-limiting modification. Only an employee's manager can change their salary Clean and performant, but white box implementation

114. 114 © Ellis Cohen 2001-2008 Access-Limiting View for Modification CREATE VIEW SalUpdatableEmpView IS SELECT * FROM Emps WHERE mgr = AuthPkg.GetUser Not only clean and performant, but achieves reusability and maintainability by hiding enforcement of the access constraint inside the view, especially if some view are based on other views BEGIN UPDATE SalUpdatableEmpView SET sal = :sal WHERE empno = :empno; CheckResults( -20044, 'You are not the employee's manager' ); EXCEPTION WHEN OTHERS THEN doerr(); END; ChangeSal( :empno, :sal )

115. 115 © Ellis Cohen 2001-2008 Modifying Complex Views If an access-limiting view is too complex to be updated directly, it can still be used in a subquery to constrain the tuples to be modified BEGIN UPDATE SomeEmpView SET … WHERE empno = :empno CheckResults( -20066, 'You cannot do this!' ); EXCEPTION WHEN OTHERS THEN doerr(); END; DoSomethingTo( :empno, … ) UPDATE Emps SET … WHERE empno = :empno AND empno IN (SELECT empno FROM SomeEmpView);

116. 116 © Ellis Cohen 2001-2008 Access-Control Views for Update CREATE VIEW UpdatableSalEmps IS SELECT empno FROM Emps WHERE mgr = AuthPkg.GetUser BEGIN UPDATE Emps SET sal = :sal WHERE empno = :empno AND empno IN (SELECT empno FROM UpdatableSalEmps); CheckResults( -20044, 'You are not the employee's manager' ); EXCEPTION WHEN OTHERS THEN doerr(); END; ChangeSal( :empno, :sal ) In fact, this approach allows the view to only be used to control access, without combining access control with the semantics of what is being updated

117. 117 © Ellis Cohen 2001-2008 Access-Control View for Query CREATE VIEW EmpMgrs IS SELECT empno FROM Emps WHERE empno = AuthPkg.GetUser OR mgr = AuthPkg.GetUser Hides the access constraint enforcement in the view. Separates the operation from the constraint SELECT empno, ename, sal FROM Emps NATURAL JOIN EmpMgrs ShowSals

118. 118 © Ellis Cohen 2001-2008 Enforcement Approaches Conditional Code (--) –Limits reusability & maintainability Inline Exceptions (-) –More maintainable Reusable Check Procedures –Clean, reusable & maintainable Access-Limiting Queries & Modifications –White box implementation, but can result in significantly cleaner code with better performance Access-Limiting Views (+) –Still clean & performant, with enhanced reusability & maintainability

119. 119 © Ellis Cohen 2001-2008 Trigger-Based Enforcement

120. 120 © Ellis Cohen 2001-2008 Access Constraint Contexts Constraint contexts for relational access constraints can either be Operation-Based –Characterizes an operation (or operation) and can refer to its parameters Table-Based –Characterizes tables accessed, but not specific operations

121. 121 © Ellis Cohen 2001-2008 Constraint Context Example Access Constraint: Only an employee's manager can change their salary Operation-Based Constraint Context (consider which operations can violate the constraint) ChangeSal Table-Based Constraint Context (consider which table modifications can violate the constraint) UPDATE OF sal ON Emps

122. 122 © Ellis Cohen 2001-2008 Relational Constraint Alternatives ChangeSal( :empno, :sal ) REQUIRES % USER = (SELECT mgr FROM Emps WHERE empno = :empno) Operation-Based Table-Based UPDATE OF sal ON Emps REQUIRES EACH Emps& e WHERE e IS UPDATED AT sal SATISFIES % USER = e.mgr Constrains each row being updated

123. 123 © Ellis Cohen 2001-2008 Reusable Check Procedures with Data-Tier Identity BEGIN CheckManage( :empno ); UPDATE Emps SET sal = :sal WHERE empno = :empno; EXCEPTION WHEN OTHERS THEN doerr(); END; ChangeSal( :empno, :sal ) PROCEDURE CheckManage( anEmpno int ) IS knt int; BEGIN SELECT count(*) INTO knt FROM Emps WHERE empno = anEmpno AND mgr = AuthPkg.GetUser; IF (knt = 0) THEN RAISE_APPLICATION_ERROR( -20044, 'You are not the employee's manager' ); END IF; END; No need to pass the current user as a parameter!

124. 124 © Ellis Cohen 2001-2008 Table-Based Enforcement Using Triggers CREATE OR REPLACE TRIGGER mgr_sal BEFORE UPDATE OF sal ON Emps FOR EACH ROW CALL CheckManage( :OLD.empno ) We can use almost the same version of CheckManage that we used for Application-Based Enforcement But, CheckManage queries the Emps table. To avoid a Mutating Table error, we need to use an autonomous transaction BEGIN UPDATE Emps SET sal = :sal WHERE empno = :empno; EXCEPTION WHEN OTHERS THEN doerr(); END; ChangeSal( :empno, :sal )

125. 125 © Ellis Cohen 2001-2008 Triggered CheckManage PROCEDURE CheckManage( anEmpno int ) IS PRAGMA AUTONOMOUS_TRANSACTION; knt int; BEGIN SELECT count(*) INTO knt FROM Emps WHERE empno = anEmpno AND mgr = AuthPkg.GetUser; IF (knt = 0) THEN ROLLBACK; RAISE_APPLICATION_ERROR( -20044, 'You are not the employee's manager' ); END IF; COMMIT; END; CheckManage must use an autonomous transaction since it is called from a row trigger where Emps is updated. Remember though, that in some cases, you can get erroneous results if multiple tuples are updated, since the transaction sees the table state before the operation started.

126. 126 © Ellis Cohen 2001-2008 Better Trigger-Based Enforcement CREATE OR REPLACE TRIGGER mgr_sal BEFORE UPDATE OF sal ON Emps FOR EACH ROW BEGIN IF :OLD.mgr != AuthPkg.GetUser THEN RAISE_APPLICATION_ERROR( -20044, 'You are not the employee's manager' ); END IF; END; The advantage of row triggers is that they have access to the before & after values of all fields in the row being modified. This often makes it possible to avoid querying the triggered table! BEGIN UPDATE Emps SET sal = :sal WHERE empno = :empno; EXCEPTION WHEN OTHERS THEN doerr(); END; ChangeSal( :empno, :sal )

127. 127 © Ellis Cohen 2001-2008 Trigger for Prevention vs Access-Limiting Modification BEGIN UPDATE Emps SET sal = :sal WHERE empno = :empno AND mgr = AuthPkg.GetUser; CheckResults( -20044, 'You are not the employee's manager' ); EXCEPTION WHEN OTHERS THEN doerr(); END; ChangeSal( :empno, :sal ) The trigger check :OLD.mgr != AuthPkg.GetUser is very similar to the code used in the access limiting modification, since it also constrains the row being modified Access-limiting modification.

128. 128 © Ellis Cohen 2001-2008 Using Access-Limiting Modification for Causal Access Restrictions BEGIN UPDATE Emps SET sal = sal * :vary WHERE mgr = :curuser; EXCEPTION WHEN OTHERS THEN doerr(); END; RaiseSal( :vary ) How could a trigger be used instead? + Access Constraint: Only an employee's manager can change their salary White box enforcement

129. 129 © Ellis Cohen 2001-2008 Using Triggers for Restriction CREATE OR REPLACE TRIGGER mgr_sal BEFORE UPDATE OF sal ON Emps FOR EACH ROW BEGIN IF :OLD.mgr != AuthPkg.GetUser THEN :NEW.sal := :OLD.sal; END; Any attempts to raise the salary of an employee who is not managed by the current user is undone BEGIN UPDATE Emps SET sal = sal * :vary; EXCEPTION WHEN OTHERS THEN doerr(); END; RaiseSal( :vary ) Black box enforcement

130. 130 © Ellis Cohen 2001-2008 Enforcement Approaches Conditional Code (--) –Limits reusability & maintainability Inline Exceptions (-) –More maintainable Reusable Check Procedures –Clean, reusable & maintainable Access-Limiting Queries & Modifications –White box implementation, but can result in significantly cleaner code with better performance Access-Limiting Views (+) –Clean & performant, with enhanced reusability & maintainability Triggers (++) –Very reusable, may be more complex to maintain, but operation-independent

131. 131 © Ellis Cohen 2001-2008 Limiting READ Access CREATE OR REPLACE TRIGGER … BEFORE ? ON Emps … Access Constraint: Only an employee or their manager can access their salary There are no SELECT Triggers Triggers can only monitor modification of tables! Can we use triggers to enforce informational access constraints?

132. 132 © Ellis Cohen 2001-2008 Oracle Security Policies Triggers allow access constraints –to be associated with a table (and the way it is accessed: UPDATE / INSERT / DELETE) –to be enforced independently of the actual operation code Oracle has a mechanism (called Security Policies) –allows policies to be associated with a table (and the way it is accessed including SELECT) –specifies a condition to be added automatically to the WHERE clause of those accesses – i.e. a black box approach to access-limiting modification and query