Should Invoker Rights be used?

Preview:

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?

Citation preview

Patrick.Barel@AMIS.nl

technology.amis.nl

blog.bar-solutions.com

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…

Patrick.Barel@GMail.com

Contact me…

@patch72 patrick@bar-solutions.com

Patrick.Barel@AMIS.nl

Patrick.Barel@GMail.com

3029156

40338721

Patrick Barel

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)

Recommended