Flexible Support for
Multiple Access Control Policies
by
Sushil Jajodia, Pierangela Samarati, Maria Luisa Sapino,
and V.S. Subrahmanian
Presented by: Rick Knowles
14 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
.
.
.
.
(o, s, +a)



propagation
policy
authorization
table
conflict resol.
and decision
policy
.
.
.
.
history
table
integrity
constraints
granted/denied
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
Mail
univ
jim
ed
personal
val

accts
mom dad
sis
staff
jim
images
faculty
ed
gif
val
a.gif
jpg
b.gif
c.jpg
Example of an OO structure
text
image
ascii
word
html
f1 f2
f3.doc f4.doc
f5.htm
gif
f6.gif f7.gif
other
tiff
f8.tiff f9.tiff
video
f10.mpg
audio
f11.au
d.jpg
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
Public
Citizens
CS-Dept
Eng-Dept
Non-Citizens
CS-Faculty
Jim
Mary
Jeremy
George
Lucy
Mike
Sam
Components:
Intuitive Definitions (cont)

Roles



Users assume roles
Privileges apply only while user is acting in
the role
Named collections of privileges
Employee
Adm-Staff
Secretary
Dean
Research-Staff
Chair
Faculty
Researcher
Components:
Formal Definitions - Hierarchy

A hierarchy is a triple (X, Y, 7) where:


X and Y are disjoint sets
7 is a partial order on (X U Y) such that each x 0
X is a minimal element of (X U Y); an element x 0
X is said to minimal iff there are no elements
below it in the hierarchy, that is iff [y 0 (X U Y); y
7 x L y = x.




Object/Type hierarchy is the triple OTH=(Obj,T,7OT)
User/Group hierarchy is the triple UGH=(U,G,7UG)
Role hierarchy is the triple RH =(f,R,7R)
Two hierarchies H1=(X1,Y1,71) and
H2=(X2,Y2,72) are disjoint iff (X1 U Y1)
Y2) = f
u
(X2
U
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,7OT) is an object-type hierarchy;
UGH=(U,G,7UG) is a user-group hierarchy;
RH is a role hierarchy RH =(f,R,7R);
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,
7AS), where 7AS is defined as follows: x 7AS y iff {x,y} 5 U U
G & x 7UG y or {x,y} 5 R & x 7R y
Intuitively, the graph of ASH is obtained by placing the graphs
of UGH and RH side by side.
Public Employee
Citizens Adm-Staff CS-Dept Research Eng-Dept Research Non-Citizens Employee
CS-Faculty Research
Jim Sec Mary Sec Jeremy Dean
George Chair
Lucy Researcher
Mike Faculty Sam Faculty
Authorizations:
Authorization Hierarchies (cont)

Authorization Object Hierarchy (AOH)


Let DS=(OTH,UGH,RH,A,Rel) be a data system.
AOH=(Obj,T U R, 7AO), where 7AO is defined as follows:
x 7AO y iff {x,y} 5 Obj U T & x 7OT y or {x,y} 5 R & x
7R y
Intuitively, the graph of AOH is obtained by placing the
graphs of OTH and the inverse of RH side by side.
Mail Secretary
Univ Adm-Staff
jim
ed
val
accts Dean
personal Adm-Staff staff Adm-Staff
mom dad
sis
jim
ed
faculty Faculty
val EMPLOYEE
Authorizations:
Definition of Authorization


Definition: An authorization is a triple of the
form (o,s,(sign)a) where o 0 AO, s 0 AS, a 0
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
u1

G4(o,-a)
G6(o,-a)

R=f
AUTH =
{(o,G1,+a),
(o,G2,-a),
(o,G4,-a),
(o,G6,-a)}
u2
Why do we need a propagation policy?


G3

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’ 6 AUTH
Authorizations:
Propagation Policies (cont)

G1 (o, +a)

(o, -a) G2
G5
G3
G4(o,-a)
G6(o,-a)

u1
R=f
AUTH =
{(o,G1,+a),
(o,G2,-a),
(o,G4,-a),
(o,G6,-a)}
u2
No propagation
AUTH’ = AUTH

[x U X U Y:
(z,+a) U lHAUTH’ (x) O (z,+a) U lHAUTH (x)
(z,-a) U lHAUTH’ (x) O (z,-a) U lHAUTH (x)

Authorizations:
Propagation Policies (cont)

G1 (o, +a)

(o, -a) G2
(o,+a)
(o,-a) G5
(o,+a)
G3 (o, +a)
G4(o,-a)
(o,+a)
G6(o,-a)
(o, +a)

(o,-a) u1
(o,+a)
u2(o,-a)
(o,+a)
R=f
AUTH =
{(o,G1,+a),
(o,G2,-a),
(o,G4,-a),
(o,G6,-a)}
No overriding
All authorizations are propagated to the
subnodes

[x U X U Y:
(z,+a) U lHAUTH’ (x) O \y U X U Y, x 7 y,
(z,+a) U lHAUTH (y)
(z,-a) U lHAUTH’ (x) O \y U X U Y, x 7 y,
(z,-a) U lHAUTH (y)

Authorizations:
Propagation Policies (cont)

G1 (o, +a)

(o, -a) G2
G3 (o, +a)
(o, -a) G5
G6(o,-a)
G4(o,-a)

Most specific overrides
Authorizations to a node are propagated to subnodes
if not overridden

[x U X U Y:
(z,+a) U lHAUTH’ (x) O \y, \w U X U Y, y=w, x 7 y, x
7 w 7 y, (z,+a) U lHAUTH (y), (z,-a) U lHAUTH (w)

[x U X U Y:
(z,-a) U lHAUTH’ (x) O \y, \w U X U Y, y=w, x 7 y, x 7
w 7 y, (z,-a) U lHAUTH (y), (z,+a) U lHAUTH (w)

(o, -a) u1
u2(o,-a)
R=f
AUTH =
{(o,G1,+a),
(o,G2,-a),
(o,G4,-a),
(o,G6,-a)}
Authorizations:
Propagation Policies (cont)

G1 (o, +a)

(o, -a) G2
G3 (o, +a)
(o, -a) G5
G6(o,-a)
G4(o,-a)

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 U X U Y:
(z,+a) U lHAUTH’ (x) O \y,p,\w U X U Y, y=w, p is a path
between x and y in H, w appears in p, (z,+a) U lHAUTH
(y), (z,-a) U lHAUTH (w)

[x U X U Y:
(z,+a) U lHAUTH’ (x) O \y,p,\w U X U Y, y=w, p is a path
between x and y in H, w appears in p, (z,+a) U lHAUTH
(y), (z,-a) U lHAUTH (w)

(o, -a) u1
(o,+a)
u2(o,-a)
R=f
AUTH =
{(o,G1,+a),
(o,G2,-a),
(o,G4,-a),
(o,G6,-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)
(o, -a) G5
G6(o,-a)
(o, -a) u1
(o,+a)
G1 (o, +a)
G4(o,-a)
u2(o,-a)
(o, -a) G2
G3 (o, +a)
(o, -a) G5
G6(o,-a)
(o, -a) u1
(o,+a)
G4(o,-a)
u2(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)
(o, -a) G5
G6(o,-a)
(o, -a) u1
(o,+a)
G1 (o, +a)
G4(o,-a)
u2(o,-a)
(o, -a) G2
G3 (o, +a)
(o, -a) G5
G6(o,-a)
(o, -a) u1
(o,+a)
G4(o,-a)
u2(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)
(o, -a) G5
G6(o,-a)
(o, -a) u1
(o,+a)
G1 (o, +a)
G4(o,-a)
u2(o,-a)
(o, -a) G2
G3 (o, +a)
(o, -a) G5
G6(o,-a)
(o, -a) u1
(o,+a)
G4(o,-a)
u2(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



dercando



Authorizations explicitly inserted by SSO
cando(file1,john,+read)
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
.
.
.
.
(o, s, +a)



propagation
policy
authorization
table
conflict resol.
and decision
policy
.
.
.
.
history
table
integrity
constraints
granted/denied
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) C in(s,Employees,ASH) &
]in(s,Soft-Developers,ASH)
cando(file2,s,+read) C 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) C dercando(file2,s,read)
dercando(o,s,-grade) C done(o,s,r,write,t) &
in(o,Exams,AOH)
dercando(file1,s,-read) C 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) C dercando(file1,s,+a)
do(file2,s,+a) C ]dercando(file2,s,-a)
do(o,s,+read) C ]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 C in(s,Citizens,ASH) & in(s,Non-citizens,ASH)
error C cando(o,s,+a) & cando(o,s,-a)
error C do(o,s,+write) & do(o,s,+evaluate) &
in(o,Tech-reports,ASH)
Architecture
Tying 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 Strata
Level
Stratum
Predicate
Rules defining predicate
0
AS0
hie-predicate
rel-predicate
done
Base relations
Base relations
Base 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, hieand 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, hieand 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