Presenter: Vijayant Dhankhar

1. 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 2

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 3

4. Access Control Policies • Closed – positive authorizations • Open – negative authorizations • Hybrid – both • Temporal - specify an interval of time for which an authorization is to hold Conflict Resolution Strategy • resolve the inconsistent authorizations by specifying which of the authorizations in a conflicting pair ought to hold 4

5. Candidate Approaches • Simple Solution: Turing complete language • Special Purpose languages: temporal authorization language • High-level declarative language: PROLOG 5

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 6

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) 7

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 8

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 9

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 10

11. Operational Semantics • State <G|C> G: current literal or Goal C: current constraint Reduction for Definite Programs 11

12. Operational Semantics Cont’ Reduction with Negation Constructive Negation Negation as Failure 12

13. RBAC SFK Models 13

14. 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 SFK Model 14

15. Primitive Predicates in Model 15

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 16

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 17

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)] 18

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 19

20. Beyond RBAC Programs • Inheritance Policies • permission inheritance path • denial inheritance path 20

21. Beyond RBAC Programs • Defining Authorized Access 21

22. Separation of Duties (RBACC3A) • SSD  R x R • DSD  R x R 22

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 23

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 24

25. Temporal Authorizations • Authorized • Denied 25

26. Representing Time • Discrete time points (natural numbers) • constraint predicates 26

27. Temporal RBAC Examples • URA • PRA • DRA 27

28. Temporal RBAC • Derivation Rules • Example or NONSTRATIFIED – paper claims it terminates 28

29. Access Control Evaluation • Using Operational Semantics for CLP • Example: Jo requests write access on o1 on 2001/03/02, and active role r2 29

30. Results 30

31. Results (Separation of Duties) 31

32. Administrative Queries • Example: • Query: • Answer: 32

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) 33

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. 34

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) 35

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 36

37. Conclusions Cont’ • SA does Administration of rules? • User does Activate (ui, rj) fact. 37