Flexible Support for Multiple Access Control PoliciesbySushil Jajodia, Pierangela Samarati, Maria Luisa Sapino, and V.S. Subrahmanian

Presented by: Rick Knowles14 April 2005

Agenda Problem Statement Components of a Flexible Authorization

Framework Authorization Specification and Policies Authorization Specification Language Architecture of the Authorization

Framework Materializing and Maintaining Derivation

and Decision Views Conclusions

Problem Statement System Security Officers require an

authorization model that can be used to restrict access to different classes of data objects May wish to use one policy to

regulate access to one type of object and a different policy for a different type of object

Possible Solutions When the protection requirements of an

application are different from the policy built into the system, implement a new policy in code Makes tasks of verification, modification, and

enforcement of the policy difficult Specification of negative authorizations

States accesses to be denied Limited in the access policies they can

express because they rely on a single underlying data model

Our Solution: Flexible Authorization Framework (FAF)

Based on a language through which users can specify security policies to be enforced on specific accesses Allows specification of positive and

negative authorizations Incorporates notions of authorization

derivation, conflict resolution and decision strategies

Authorization Framework:What is it?

In general, it determines the circumstances under which a user may attempt to execute an access operation on a given data item.

Must answer the following questions: To what data items is the framework mediating

access and how are these data items organized? For what kinds of accesses does the framework

determine authorization privileges? How are the users/user groups organized? What types of roles may users adopt and under

what conditions may they adopt these roles? Who can administer accesses?

Architecture....

propagationpolicy

conflict resol.and decisionpolicy

integrityconstraints

authorizationtable

historytable

granted/denied(o, s, +a)

.

.

.

.

Access control is enforced with respect to the user’s id, if no role is active, and with respect to the role if a role is active

For any access, exactly one decision (allowed / denied) is provided

Policies are expressed by a tightly restricted class of logic programs

Components:Intuitive Definitions Object/Type Items

Example of a directory structure

jim ed val mom dad sis jim ed val a.gif b.gif c.jpg d.jpg

univ personal staff faculty gif jpg

Mail accts images

Example of an OO structure

f1 f2 f3.doc f4.doc f5.htm f6.gif f7.gif f8.tiff f9.tiff f10.mpg f11.au

ascii word html gif tiff video audio

text image other

Components:Intuitive Definitions (cont)

Access types Actions or operations that the user tries

to execute on different data objects read, write, move, copy…

User and User Groups Groups are named sets of users

Jim Mary Jeremy George Lucy Mike Sam

CS-Faculty

Citizens CS-Dept Eng-Dept Non-Citizens

Public

Components:Intuitive Definitions (cont)

Roles Users assume roles Privileges apply only while user is

acting in the role Named collections of privileges

Secretary Dean Chair Faculty Researcher

Adm-Staff Research-Staff

Employee

Components:Formal Definitions - Hierarchy

A hierarchy is a triple (X, Y, ) where: X and Y are disjoint sets is a partial order on (X U Y) such that each x X is

a minimal element of (X U Y); an element x X is said to minimal iff there are no elements below it in the hierarchy, that is iff y (X U Y); y x y = x.

Object/Type hierarchy is the triple OTH=(Obj,T,OT) User/Group hierarchy is the triple UGH=(U,G,UG) Role hierarchy is the triple RH =(,R,R)

Two hierarchies H1=(X1,Y1,1) and H2=(X2,Y2,2) are disjoint iff (X1 U Y1) (X2 U Y2) =

Components:Formal Definitions - Data System

A data system consists of users/groups, the data they are accessing, together with the roles they may play and the types of access modes they use

A Data System (DS) is a 5-tuple (OTH, UGH, RH, A, Rel) where:

OTH=(Obj,T,OT) is an object-type hierarchy; UGH=(U,G,UG) is a user-group hierarchy; RH is a role hierarchy RH =(,R,R); A is a set whose elements are called authorization modes

or actions; Rel is a set whose elements are called relationships.

Relationships can be defined on the different elements of DS and may be unary, binary or n-ary in nature.

Authorizations:Authorization Hierarchies

Authorization Subject Denotes those entities for which authorization privileges

can be specified Authorization Subject Hierarchy (ASH)

Let DS=(OTH,UGH,RH,A,Rel) be a data system. ASH=(U,G U R, AS), where AS is defined as follows: x AS y iff {x,y} U U G & x UG y or {x,y} R & x R y

Intuitively, the graph of ASH is obtained by placing the graphs of UGH and RH side by side.

Jim Sec Mary Sec Jeremy Dean George Chair Lucy Researcher Mike Faculty Sam Faculty

CS-Faculty Research

Citizens Adm-Staff CS-Dept Research Eng-Dept Research Non-Citizens Employee

Public Employee

Authorizations:Authorization Hierarchies (cont)

Authorization Object Hierarchy (AOH) Let DS=(OTH,UGH,RH,A,Rel) be a data system.

AOH=(Obj,T U R, AO), where AO is defined as follows: x AO y iff {x,y} Obj U T & x OT y or {x,y} R & x R y

Intuitively, the graph of AOH is obtained by placing the graphs of OTH and the inverse of RH side by side.

jim ed val mom dad sis jim ed val EMPLOYEE

Univ Adm-Staff personal Adm-Staff staff Adm-Staff faculty Faculty

Mail Secretary accts Dean

Authorizations:Definition of Authorization

Definition: An authorization is a triple of the form (o,s,(sign)a) where o AO, s AS, a A and sign is either “+” or “-”

Examples (mail, faculty, +read) (personal, faculty, -read)

Logical question: How should authorizations be propagated? Other logical question: How should conflict

resolution be managed?

Authorizations:Propagation Policies

G1 (o, +a)

(o, -a) G2

G5

G3 G4(o,-a)

G6(o,-a)

u1 u2

R = AUTH =

{(o,G1,+a), (o,G2,-a), (o,G4,-a), (o,G6,-a)}

Why do we need a propagation policy? To expand a partial labeled hierarchy

It is a map that, given a hierarchy H and an input set of AUTH of authorizations, returns as output a set AUTH’ AUTH

Authorizations:Propagation Policies (cont)

No propagation AUTH’ = AUTH x X U Y:(z,+a) H

AUTH’ (x) (z,+a) HAUTH (x)

(z,-a) HAUTH’ (x) (z,-a) H

AUTH (x)

G1 (o, +a)

(o, -a) G2

G5

G3 G4(o,-a)

G6(o,-a)

u1 u2

R = AUTH =

{(o,G1,+a), (o,G2,-a), (o,G4,-a), (o,G6,-a)}

Authorizations:Propagation Policies (cont)

No overriding All authorizations are propagated to

the subnodes x X U Y:(z,+a) H

AUTH’ (x) y X U Y, x y, (z,+a) H

AUTH (y)

(z,-a) HAUTH’ (x) y X U Y, x y, (z,-

a) HAUTH (y)

G1 (o, +a)

(o, -a) G2

(o,+a)

(o,-a) u1

(o,+a)

G3 (o, +a) G4(o,-a) (o,+a)

G6(o,-a) (o, +a)

u2(o,-a) (o,+a)

R = AUTH =

{(o,G1,+a), (o,G2,-a), (o,G4,-a), (o,G6,-a)}(o,-a)

G5

(o,+a)

Authorizations:Propagation Policies (cont)

Most specific overrides Authorizations to a node are propagated to

subnodes if not overridden x X U Y:(z,+a) H

AUTH’ (x) y, w X U Y, y=w, x y, x w y, (z,+a) H

AUTH (y), (z,-a) HAUTH (w)

x X U Y:(z,-a) H

AUTH’ (x) y, w X U Y, y=w, x y, x w y, (z,-a) H

AUTH (y), (z,+a) HAUTH (w)

G1 (o, +a)

(o, -a) G2 G3 (o, +a) G4(o,-a)

G6(o,-a)

u2(o,-a)

R = AUTH =

{(o,G1,+a), (o,G2,-a), (o,G4,-a), (o,G6,-a)}(o, -a) G5

(o, -a) u1

Authorizations:Propagation Policies (cont)

Path overrides Authorizations of a node are propagated to subnodes

if not overridden. The label attached to a node n overrides a contradicting label of a supernode n’ for all the subnodes of n only for the paths passing from n

x X U Y:(z,+a) H

AUTH’ (x) y,p,w X U Y, y=w, p is a path between x and y in H, w appears in p, (z,+a) H

AUTH (y), (z,-a) H

AUTH (w) x X U Y:(z,+a) H

AUTH’ (x) y,p,w X U Y, y=w, p is a path between x and y in H, w appears in p, (z,+a) H

AUTH (y), (z,-a) H

AUTH (w)

R = AUTH =

{(o,G1,+a), (o,G2,-a), (o,G4,-a), (o,G6,-a)}

G1 (o, +a)

(o, -a) G2 G3 (o, +a) G4(o,-a)

G6(o,-a)

u2(o,-a)

(o, -a) G5

(o, -a) u1

(o,+a)

Authorizations:Conflict Resolution Policies

Obviously, the propagation policies potentially propagate conflicts. Some of the conflict resolution policies include: No conflicts

This policy assumes no conflicts. If one occurs, an error is generated.

Authorizations:Conflict Resolution Policies (cont)

Denials take precedence Negative authorizations are always

adopted when conflict occurs. For example, using the Path Overrides

example:G1 (o, +a)

(o, -a) G2 G3 (o, +a) G4(o,-a)

G6(o,-a)

u2(o,-a)

(o, -a) G5

(o, -a) u1

(o,+a)

G1 (o, +a)

(o, -a) G2 G3 (o, +a) G4(o,-a)

G6(o,-a)

u2(o,-a)

(o, -a) G5

(o, -a) u1

(o,+a)

Authorizations:Conflict Resolution Policies (cont)

Permissions take precedence Positive authorizations are always

adopted when conflict occurs. For example, using the Path Overrides

example:G1 (o, +a)

(o, -a) G2 G3 (o, +a) G4(o,-a)

G6(o,-a)

u2(o,-a)

(o, -a) G5

(o, -a) u1

(o,+a)

G1 (o, +a)

(o, -a) G2 G3 (o, +a) G4(o,-a)

G6(o,-a)

u2(o,-a)

(o, -a) G5

(o, -a) u1

(o,+a)

Authorizations:Conflict Resolution Policies (cont)

Nothing take precedence Neither authorize nor deny an access when

conflict occurs. Instead, defer to Decision Policies For example, using the Path Overrides example:

G1 (o, +a)

(o, -a) G2 G3 (o, +a) G4(o,-a)

G6(o,-a)

u2(o,-a)

(o, -a) G5

(o, -a) u1

(o,+a)

G1 (o, +a)

(o, -a) G2 G3 (o, +a) G4(o,-a)

G6(o,-a)

u2(o,-a)

(o, -a) G5

(o, -a) u1

(o,+a)

Authorization Specification Language:Constant and Variable Symbols

Every member of Obj U T U U U G U R U A U SA Obj is the set of objects. Variable: VO

T is the set of types. Variable: VT

U is the set of users. Variable: VU

G is the set of groups. Variable: VG

R is the set of roles. Variable: VR

A is the set of signed actions. Variable: VA

SA is the set of unsigned actions. Variable: VSA

Authorization Specification Language:Predicate Symbols

cando Authorizations explicitly inserted by SSO cando(file1,john,+read)

dercando Authorizations derived by the system using logic rules dercando(file1,john,-write)

do Represents the accesses that must be granted or

denied. Enforces conflict resolution and access decision policy

do(file2,bill,+write)

Authorization Specification Language:Other Predicate Symbols done: done(o,u,r,a,t) is true if user u with role r active has

executed action a on object on at time t overAO and overAS: used in definition of the overriding

policies error: signals the violation of the integrity constraints hie-predicates

in: captures ordering relationships in AOH and ASH dirin: captures direct membership relationships in AOH and

ASH Rel-predicates

owner: associates unique user or role with object isuser, isgroup, isrole: used for propagation, conflict

resolution or decision policies

Architecture....

propagationpolicy

conflict resol.and decisionpolicy

integrityconstraints

authorizationtable

historytable

granted/denied(o, s, +a)

.

.

.

.

Access control is enforced with respect to the user’s id, if no role is active, and with respect to the role if a role is active

For any access, exactly one decision (allowed / denied) is provided

Policies are expressed by a tightly restricted class of logic programs

Architecture:History Table

Rows describe the accesses executed

Useful in implementing policies in which future accesses are based on accesses each user has made in the past (i.e., Chinese Wall policy)

done(object, user, role, action, time)

Architecture:Authorization Table

Viewed as a database Rows are authorizations

(o,s,<signed>a) Example:

cando(file1,s,+read) in(s,Employees,ASH) & in(s,Soft-Developers,ASH)

cando(file2,s,+read) in(s,Employees,ASH) & in(s,Non-citizens,ASH)

Architecture:Propagation Policy

Specifies how to obtain new derived authorizations from the explicit Authorization Table

Example dercando(file1,s,-write) dercando(file2,s,read) dercando(o,s,-grade) done(o,s,r,write,t) &

in(o,Exams,AOH) dercando(file1,s,-read) dercando(file2,s’,read)

& in(s,g,ASH) & in(s’,g,ASH)

Architecture:Conflict Resolution and Decision Policy

Specifies how to eliminate conflicts from conflicting authorizations

Determines the system’s response (yes or no) to every possible access request

Examples do(file1,s,+a) dercando(file1,s,+a) do(file2,s,+a) dercando(file2,s,-a) do(o,s,+read) dercando(o,s,+read) &

dercando(o,s,-read) & in(o,Pblc-docs,AOH)

Architecture: Integrity Rules

Imposes restrictions on the content and output of the other components

Derives an error every time the conditions on the right hand side of the equation are satisfied

Examples error in(s,Citizens,ASH) & in(s,Non-

citizens,ASH) error cando(o,s,+a) & cando(o,s,-a) error do(o,s,+write) & do(o,s,+evaluate) &

in(o,Tech-reports,ASH)

ArchitectureTying it all together Putting this all together, the SSO creates an

Authorization Specification (AS) Components

History table Authorization table Set of integrity rules hie-, rel-, and overriding predicates Derivation view Decision view

Authors developed proofs to show that the AS is a unique, stable model and that for any attempt to do action a by user s on object o, exactly one of do(o,s,+a) or do(o,s,-a) is true

Authorization Specification StrataLevel Stratum Predicate Rules defining predicate

0 AS0 hie-predicaterel-predicatedone

Base relationsBase relationsBase relation

1 AS1 cando Body may contain done, hie- and rel- literals

2 AS2 dercando Body may contain cando, dercando, done, hie-, and rel- literals. Occurrences of dercando literals must be positive

3 AS3 do In the case when head is of the form do(-,-,+a), body may contain cando, dercando, done, hie- and rel- literals

4 AS4 do In the case when head is of the form do(-,-,-a), body may contain just one literal !do(o,s,+a)

5 AS5 error Body may contain do, cando, dercando, done, hie- and rel- literals.

Materialization Structure The end goal, of course, is to create a

system that answers the question, “Can user s do action a on object o?” The proofs on AS show it can be done, but

the question is how fast? Two goals:

Request should be authorized or denied very fast Changes to the specifications are far less frequent

than access requests

Materialized Views Their answer is to develop materialized

views of the derivation and decision views Not the entire AS Just the association of each fact of the model

with the indexes of the rules that directly support its truth

Construction is an iterative process based on the AS stratum

Derivation view is AS2 Decision view is AS3

Computation of model is polynomial data complexity Computation of updates to the model are also of

polynomial data complexity

Conclusions Traditionally, most systems implement a single access

control policy The FAF approach provides the application developer

with a host of policy options SSO specifies access control requirements through explicit

authorizations together with derivation, conflict resolution and decision strategies

Different strategies may be applied to different users, groups, objects, or roles

Further work Extend model that regulate different insertions by multiple

users (not just one SSO) Extend model to represent and enforce complex security

policies of different organizations