Flexible access control policy specification with constraint

logic programming Steve Barker, Peter J. Stuckey

Presenter: Vijayant Dhankhar

2

Outline

• Introduction and Motivation• Other Proposed Approaches• Constrained Logic Programming

Intro.• RBAC SFK Model and ESFK• Results• Conclusion

3

Introduction

• Access control policies have been limited in expressive power

• Allow simple types of access policy to be defined for protecting simple types of information systems.

Goal:• flexibly represent access policies for

protecting the increasingly diverse and complex types of systems

4

Access Control Policies

• Closed – positive authorizations• Open – negative authorizations• Hybrid – both• Temporal - specify an interval of time for

which an authorization is to holdConflict Resolution Strategy• resolve the inconsistent authorizations by

specifying which of the authorizations in a conflicting pair ought to hold

5

Candidate Approaches

• Simple Solution: Turing complete language

• Special Purpose languages: temporal authorization language

• High-level declarative language: PROLOG

6

Approach (LP vs. CLP)

• conciseness of specification• easily understandable• strong technical results that enable

properties of a policy to be proved• enable certain policies to be formulated

that cannot be satisfactorily represented in LP

• efficiency• uninstantiated arithmetic variables

7

CLP

• primitive constraint [p(t1… tn) ; arity = n]• constraint

– conjunction of primitive constraints• c1 ^ c2 ^ …. ^ ck

• equational constraints• t1 = t2 or t1 t2 (eg. User = Fred)

• constraints over nonnegative integers

• T = 3 or X > Y or Y = (Z ÷ 1000)

8

CLP cont’

• literal – primitive constraint– atom

• User Defined Predicate Symbol– p(t1,…,tn)

• goal • sequence of literals L1 ^ …. ^ Lm

• rule• H L1 ^ …. ^ Lk or [ ]• Head: H; Body: L1 ^ …. ^ Lk

• If k=0 then Rule is a Fact

9

CLP cont’

• constraint logic program () is a finite set of rules

• definite program • no negative literals• could be cyclic

• stratified program• allows negative literals• no cycle with negative edge

• recursion free programs • allow negative literal• no cycles• terminate

10

CLP cont’

• definition of n-place predicate symbol in logic program

» Where Bi is rule of form

• Clark Completion *

• Conjunction of definitions of user defined predicates in

• Solver solv: C Bool

11

Operational Semantics

• State <G|C> G: current literal or Goal C: current constraint

Reduction for Definite Programs

12

Operational Semantics Cont’

Reduction with NegationConstructive Negation

Negation as Failure

13

RBAC SFK Models

14

SFK Model

Domain:• A set U of user

identifiers• A set O of object

identifiers• A set A of access

privilege identifiers

• A set R of role identifiers

Relations:• AUTHORIZATION

U x A x O• PERMISSION A x

O• URA U x R• PRA A x O x R• DRA A x O x R• ACTIVE U x R

15

Primitive Predicates in Model

16

Representing RBAC Programs

• Role Hierarchies in RBAC Programs– DS: irreflexive and intransitive hence

acyclic– senior_to: represented as Facts

(finite/non recursive)

• NOTE: set of n2 Facts at worst

17

Representing RBAC Programs

• Sessions– appending an activate(ui , rj) fact.

– RULE: (active(U, R) activate(U, R))– deactivates a role R1 by retracting

the appropriate activate fact

• User-Role Review: – to extract information about the

access policy the program represents

18

Representing RBAC Programs

• Authorized Access

• permitted assumes that the activation by U of R1 also activates all roles that are junior to R1

• Activation policy [check active(U, R2)]

19

Beyond RBAC Programs

• Denial Role Assignments– Authorization expressed in terms of

pra dra senior_to, etc.– Various policies implementable

• Object Hierarchies• irreflexive-intransitive DI• reflexive transitive INCLUDES

20

Beyond RBAC Programs

• Inheritance Policies– permission inheritance path– denial inheritance path

21

Beyond RBAC Programs

• Defining Authorized Access

22

Separation of Duties (RBACC3A)

• SSD R x R

• DSD R x R

23

Permission Role Review (RBACS4A)

• To extend RBACC3A programs to RBACS4A programs, permission-role and denial-role reviews must be supported.– pra queries– dra queries

24

Temporal Authorizations

• enable a SA to specify that user access to a data item for a restricted interval of time

• Paper considers RBACH2A • an extra argument is added to the

ura, pra, and dra predicates

25

Temporal Authorizations

• Authorized

• Denied

26

Representing Time

• Discrete time points (natural numbers)– constraint predicates

27

Temporal RBAC Examples

• URA

• PRA

• DRA

28

Temporal RBAC

• Derivation Rules– Example

or

NONSTRATIFIED – paper claims it terminates

29

Access Control Evaluation

• Using Operational Semantics for CLP– Example: Jo requests write access on o1 on

2001/03/02, and active role r2

30

Results

31

Results (Separation of Duties)

32

Administrative Queries

• Example:

• Query:• Answer:

33

Performance Measures

• 53 role RBAC H2A role hierarchy (a total of 312 senior to facts)

• 530 users and 497 objects.• 650 ura rules, 1092 dra rules, and 1185 pra rules• simple solver (LP), constraint solving specialized(CLP)

34

Future Work

• In future work we want to consider how other forms of limitation on access– accessing objects only at certain

locations– from certain machines – etc.

35

Conclusions

• Could be easily extended to do Administrative RBAC (predicate admin_scope etc..).

• Use of Negation as Failure instead of Constructive Negation.– Administrative Queries with negation– Not as expressive in policy (can not

create new bindings for query variables)

36

Conclusions Cont’

• No restrictions specified to make the program Stratified or Recursion Free.– In case of derivations, 3 valued to 2

valued consequence (does it hold?). • [Ura(…) L1 ^ not Ura(…)]

• History based constraints should be added to ESFK model.– Help in modeling states in Temporal

RBAC

37

Conclusions Cont’

• SA does Administration of rules?– User does Activate (ui, rj) fact.