AMIS definer invoker rights

302
-1

Published on

Deze presentatie is gegeven tijdens de KScope conferentie 2012

Spreker: Patrick Barel
Titel: Should Invoker Rights Be Used?
Onderwerp: Developers Toolbox - Coding

Deze presentatie gaat over de vraag of het Invoker Rights model van de Oracle Database, voor verschillende gebruikers binnen dezelfde database, kan helpen bij het scheiden van de zichtbaarheid van de data. Door gebruik te maken van de techniek deze techniek kun je op een relatief eenvoudige wijze ervoor zorgen dat gebruikers alleen werken op hun eigen data en niet op die van anderen. Als het bijvoorbeeld gaat om een hosted applicatie, dan hoeft er nog maar één codebase te zijn, waardoor alle gebruikers direct profiteren van verbeteringen die aangebracht worden. Daarnaast leer je in deze sessie hoe je één set code kunt onderhouden voor verschillende gebruikers van de applicatie en hoe je je ‘gedeeltelijk’ kunt beschermen tegen SQL Injection.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
302
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

AMIS definer invoker rights

  1. 1. Developers Toolbox – Coding Should invoker rights be used?Patrick Barel , AMIS, The NetherlandsMonday, June 25, 2012ODTUG KScope 12San Antonio, Texas, USA
  2. 2. Definer Rights vs Invoker Rights Prior to Oracle8i, whenever you executed a stored program, it ran under the privileges of the account in which the program was defined.  This is called the … Definer Rights Model With Oracle8i, you can now decide at compilation time whether your program or package will execute in the definers schema (the default) or the schema of the invoker of the code.  This is called the … Invoker Rights Model
  3. 3. Definer RightsPatrick Mitchell Code Invoke R e fRelations Relations
  4. 4. Invoker RightsPatrick Mitchell Code InvokeRelations Relations
  5. 5. Invoker Rights Allows you to centralize access to and control of underlying data structures. Uses roles and doesn’t rely on directly-granted privileges. But it can be a source of confusion and architectural problems. Note: Oracle built-in packages have long had the capability of running under the invokers authority.
  6. 6. What’s wrong with Definer Rights Deployment & maintenance  Must install module in all schemas where needed  In some databases, each user has own copy of table(s), requiring copy of stored module Security  No declarative way to restrict privileges on certain modules in a package -- its all or nothing, unless you write code in the package to essentially recreate roles programmatically.  Difficult to audit privileges Sure would be nice to have a choice...and now you do!
  7. 7. Invoker Rights For top level modules: CREATE [ OR REPLACE ] <module type> [ AUTHID { DEFINER | CURRENT_USER } ] AS ... For modules with separate spec and body, AUTHID goes only in spec, and must be at the package level. Holds true for packages and object types.
  8. 8. Overview of Definer Rightsbegin package y x.foo; authid package x definerend; authid definer package z authid definer Emp Emp Emp
  9. 9. Overview of Invoker Rightsbegin package y x.foo; authid package x definerend; authid current_user package z authid current_user Emp Emp Emp
  10. 10. Overview of Invoker Rights begin x.foo; end; package y Emp authid package x definer authid current_userbegin package z x.foo; authidend; current_user Emp Emp Emp
  11. 11. Mock objectsTo compile code you still need the structure of theobjects.
  12. 12. Mock objectsbegin begin x.foo; x.foo; package xend; end; Execute authid Execute current_userCol1 Col2 Col3 Col4 Col1 Col2 Col3 Col4A.val1 A.val2 A.val3 A.val4 B.val1 B.val2 B.val3 B.val4A.val5 A.val6 A.val7 A.val8 B.val5 B.val6 B.val7 B.val8A.val9 A.val10 A.val11 A.val12 B.val9 B.val10 B.val11 B.val12A.val13 A.val14 A.val15 A.val16 B.val13 B.val14 B.val15 B.val16 Col1` Col2 Col3 Col4
  13. 13. Definer Rights Use a single codebase for multiple users (a bit of) Protection from SQL Injection
  14. 14. Single codebaseUser1 User2 App Mock objects
  15. 15. Single codebaseUser1 User2 App Code
  16. 16. Single codebaseUser1 User2 App
  17. 17. Single codebaseApplication code in a central schema (with mock objects) User1 User2 App
  18. 18. Single codebaseEach user has it’s own set of tables, views and sequences User1 User2 App
  19. 19. Single codebase Columns can be different in each schemaUser1 User2 App
  20. 20. Advantages One time development Specific code in user schema (partial) Protection from SQL Injection
  21. 21. Drawbacks Debugging can be hard Support can be hard
  22. 22. SQL Injection Dynamic SQL  Modification (drop) of objects You cannot drop what is not there  Modification of records Will only affect current users data You should always use binding instead of concatenating in Dynamic SQL Statements
  23. 23. Rules and RestrictionsAUTHID DEFINER Definer Rights Model Uses directly granted privileges Default, so no need to change current codeAUTHID CURRENT_USER Invoker Rights Model Uses ROLEs On entire objects Need for ‘mock’ objects (at compile time it’s Definer Rights)
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×