should invoker rights be used?
DESCRIPTION
How can you ensure users use only their data and not someone elses. How can you do this with minimal effort? How can you get rid of multiple codebases. How can you (partially) protect yourself against SQL Injection. In this session we explore the use of the different authentication models in the Oracle database. When do you use the Definer Rights model and when could, or should, you use the Invoker Rights model?TRANSCRIPT
About me…
• Patrick Barel
• Working with Oracle since 1997
• Working with PL/SQL since 1999
• Playing with APEX since 2003 (mod_plsql)
• ACE since 2011
• OCA since December 20th 2012
Read me…
http://blog.bar-solutions.com
http://technology.amis.nl
http://allthingsoracle.com
Download me…
Plugins for PL/SQL Developer
http://bar-solutions.com
Plugins for Apex
http://apex-plugin.com
Watch me…
Steven Feuerstein Masterclass
Anti-Pattern PL/SQL Programming +
Oracle Database 12c New PL/SQL Features
12/13 December. AMIS, Nieuwegein
• Steven will present examples of "bad code"
(anti-patterns) and features of PL/SQL that
address them.
• Students working in pairs then use their
laptops to fix the anti-patterns.
• Steven then walks entire class through
optimal solutions.
Definer Rights Model
Invoker Rights Model
� 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 …
� With Oracle8i, you can now decide at compilation time whether your program or package will execute in the definer's schema (the default) or the schema of the invokerof the code.
� This is called the …
Definer Rights vs Invoker Rights
Patrick Mitchell
Code Invoke
R
e
f
Relations Relations
Definer Rights
Patrick Mitchell
Code Invoke
Relations Relations
Invoker Rights
�Allows you to centralizeaccess to and control ofunderlying data structures.
�Uses roles and doesn’t relyon directly-granted privileges.
�But it can be a source of confusion andarchitectural problems.
Note: Oracle built-in packages have long had the capability of running under the invoker's authority.
Invoker Rights
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 -- it's 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!
� 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 -- it's 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!
What’s wrong with Definer Rights
CREATE [ OR REPLACE ] <module type>
[ AUTHID { DEFINER | CURRENT_USER } ]
AS ...
Invoker Rights
�For top level modules:
�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.
Emp
begin
x.foo;
end;package x
authid
definer
Emp Emp
package y
authid
definer
package z
authid
definer
Overview of Definer Rights
Emp
begin
x.foo;
end;package x
authid
current_user
Emp Emp
package y
authid
definer
package z
authid
current_user
Overview of Invoker Rights
Emp
begin
x.foo;
end;
package x
authid
current_user
Emp Emp
package y
authid
definer
package z
authid
current_user
Emp
begin
x.foo;
end;
Overview of Invoker Rights
Mock objects
To compile code you still need the structure of the objects.
begin
x.foo;
end;
begin
x.foo;
end;package x
authid
current_user
Col1` Col2 Col3 Col4
Col1 Col2 Col3 Col4
A.val1 A.val2 A.val3 A.val4
A.val5 A.val6 A.val7 A.val8
A.val9 A.val10 A.val11 A.val12
A.val13 A.val14 A.val15 A.val16
Col1 Col2 Col3 Col4
B.val1 B.val2 B.val3 B.val4
B.val5 B.val6 B.val7 B.val8
B.val9 B.val10 B.val11 B.val12
B.val13 B.val14 B.val15 B.val16
Execute Execute
Mock objects
Definer Rights
Definer rights
Single codebase
SQL Injection
Definer Rights
� Use a single codebase for multiple users
� (a bit of) Protection from SQL Injection
Single codebase
User1 User2
App
User1 User2
App
Mock objects
Single codebase
User1 User2
App
Code
Single codebase
User1 User2
App
Single codebase
User1 User2
App
Application code in a central schema (with mock objects)
Single codebase
User1 User2
App
Each user has it’s own set of tables, views and sequences
Single codebase
User1 User2
App
Columns can be different in each schema
Single codebase
demo_ir.sqldemo_ir.sql
Advantages
�One time development
�Specific code in user schema
� (partial) Protection from SQL Injection
Drawbacks
�Debugging can be hard
�Support can be hard
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
Definer Rights Model
Invoker Rights Model
Rules and Restrictions
• AUTHID DEFINER
– Uses directly granted
privileges
– Default, so no need to change current code
• AUTHID CURRENT_USER
– Uses ROLEs
– On entire objects
– Need for ‘mock’ objects– (at compile time it’s Definer Rights)
