Flexible Support for Multiple Access Control Policies

1. Flexible Support for Multiple Access Control PoliciesbySushil Jajodia, Pierangela Samarati, Maria Luisa Sapino, and V.S. Subrahmanian Presented by: Rick Knowles 14 April 2005

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

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

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

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

6. 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?

7. . . . . . . . . authorization table history table propagation policy conflict resol. and decision policy integrity constraints (o, s, +a) granted/denied Architecture • 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

8. Mail accts images univ personal staff faculty gif jpg jim ed val mom dad sis jim ed val a.gif b.gif c.jpg d.jpg text image other ascii word html gif tiff video audio f1 f2 f3.doc f4.doc f5.htm f6.gif f7.gif f8.tiff f9.tiff f10.mpg f11.au Components:Intuitive Definitions • Object/Type Items • Example of a directory structure • Example of an OO structure

9. Public Citizens CS-Dept Eng-Dept Non-Citizens CS-Faculty Jim Mary Jeremy George Lucy Mike Sam 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

10. Employee Adm-Staff Research-Staff Secretary Dean Chair Faculty Researcher Components:Intuitive Definitions (cont) • Roles • Users assume roles • Privileges apply only while user is acting in the role • Named collections of privileges

11. 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 (X1U Y1) u (X2U Y2) = f

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

13. 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 • 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.

14. 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 accts Dean Univ Adm-Staff personal Adm-Staff staff Adm-Staff faculty Faculty jim ed val mom dad sis jim ed val EMPLOYEE

15. 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?

16. G1 (o, +a) G3 G4(o,-a) (o, -a) G2 G5 G6(o,-a) u1 u2 Authorizations:Propagation Policies • R = f • 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’ 6 AUTH

17. G1 (o, +a) G3 G4(o,-a) (o, -a) G2 G5 G6(o,-a) u1 u2 Authorizations:Propagation Policies (cont) • No propagation • AUTH’ = AUTH • [x U X U Y: (z,+a) UlHAUTH’ (x) O (z,+a) UlHAUTH (x) (z,-a) UlHAUTH’ (x) O (z,-a) UlHAUTH (x) • R = f • AUTH = {(o,G1,+a), (o,G2,-a), (o,G4,-a), (o,G6,-a)}

18. Authorizations:Propagation Policies (cont) • No overriding • All authorizations are propagated to the subnodes • [x U X U Y: (z,+a) UlHAUTH’ (x) O\y U X U Y, x 7 y, (z,+a) UlHAUTH (y) (z,-a) UlHAUTH’ (x) O\y U X U Y, x 7 y, (z,-a) UlHAUTH (y) • R = f • AUTH = {(o,G1,+a), (o,G2,-a), (o,G4,-a), (o,G6,-a)} G1 (o, +a) G3 (o, +a) G4(o,-a) (o,+a) (o, -a) G2 (o,+a) (o,-a) G5 (o,+a) G6(o,-a) (o, +a) u2(o,-a) (o,+a) (o,-a) u1 (o,+a)

19. Authorizations:Propagation Policies (cont) • Most specific overrides • Authorizations to a node are propagated to subnodes if not overridden • [x U X U Y: (z,+a) UlHAUTH’ (x) O\y, \w U X U Y, y=w, x 7 y, x 7 w 7 y, (z,+a) UlHAUTH (y), (z,-a) UlHAUTH (w) • [x U X U Y: (z,-a) UlHAUTH’ (x) O\y, \w U X U Y, y=w, x 7 y, x 7 w 7 y, (z,-a) UlHAUTH (y), (z,+a) UlHAUTH (w) • R = f • AUTH = {(o,G1,+a), (o,G2,-a), (o,G4,-a), (o,G6,-a)} G1 (o, +a) G3 (o, +a) G4(o,-a) (o, -a) G2 (o, -a) G5 G6(o,-a) (o, -a) u1 u2(o,-a)

20. G1 (o, +a) G3 (o, +a) G4(o,-a) (o, -a) G2 (o, -a) G5 G6(o,-a) (o, -a) u1 (o,+a) u2(o,-a) 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 U X U Y: (z,+a) UlHAUTH’ (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) UlHAUTH (y), (z,-a) UlHAUTH (w) • [x U X U Y: (z,+a) UlHAUTH’ (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) UlHAUTH (y), (z,-a) UlHAUTH (w) • R = f • AUTH = {(o,G1,+a), (o,G2,-a), (o,G4,-a), (o,G6,-a)}

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

22. G1 (o, +a) G1 (o, +a) G3 (o, +a) G3 (o, +a) G4(o,-a) G4(o,-a) (o, -a) G2 (o, -a) G2 (o, -a) G5 (o, -a) G5 G6(o,-a) G6(o,-a) (o, -a) u1 (o,+a) (o, -a) u1 (o,+a) u2(o,-a) u2(o,-a) Authorizations:Conflict Resolution Policies (cont) • Denials take precedence • Negative authorizations are always adopted when conflict occurs. • For example, using the Path Overrides example:

23. G1 (o, +a) G1 (o, +a) G3 (o, +a) G3 (o, +a) G4(o,-a) G4(o,-a) (o, -a) G2 (o, -a) G2 (o, -a) G5 (o, -a) G5 G6(o,-a) G6(o,-a) (o, -a) u1 (o,+a) (o, -a) u1 (o,+a) u2(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:

24. G1 (o, +a) G1 (o, +a) G3 (o, +a) G3 (o, +a) G4(o,-a) G4(o,-a) (o, -a) G2 (o, -a) G2 (o, -a) G5 (o, -a) G5 G6(o,-a) G6(o,-a) (o, -a) u1 (o,+a) (o, -a) u1 (o,+a) u2(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:

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

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

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

28. . . . . . . . . authorization table history table propagation policy conflict resol. and decision policy integrity constraints (o, s, +a) granted/denied Architecture • 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

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

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

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

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

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

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

35. Authorization Specification Strata

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

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

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