presenter: vijayant dhankhar
DESCRIPTION
Flexible access control policy specification with constraint logic programming Steve Barker, Peter J. Stuckey. Presenter: Vijayant Dhankhar. Outline. Introduction and Motivation Other Proposed Approaches Constrained Logic Programming Intro. RBAC SFK Model and ESFK Results Conclusion. - PowerPoint PPT PresentationTRANSCRIPT
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.