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

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. Architecture........ propagation policy conflict resol. and decision policy integrity constraints authorization table history table granted/denied(o, s, +a)........ 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. Components: Intuitive Definitions Object/Type Items Example of a directory structure jim ed val mom dad sis jim ed val a.gif b.gif c.jpg d.jpg univ personal staff faculty gif jpg Mail accts images Example of an OO structure f1 f2 f3.doc f4.doc f5.htm f6.gif f7.gif f8.tiff f9.tiff f10.mpg f11.au ascii word html gif tiff video audio text image other

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

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

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, 7 OT ) User/Group hierarchy is the triple UGH=(U,G, 7 UG ) Role hierarchy is the triple RH =( ,R, 7 R ) Two hierarchies H 1 =(X 1,Y 1, 7 1 ) and H 2 =(X 2,Y 2, 7 2 ) are disjoint iff (X 1 U Y 1 ) u (X 2 U Y 2 ) = 

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, 7 OT ) is an object-type hierarchy; UGH=(U,G, 7 UG ) is a user-group hierarchy; RH is a role hierarchy RH =( ,R, 7 R ); 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. 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, 7 AS ), where 7 AS is defined as follows: x 7 AS y iff {x,y} 5 U U G & x 7 UG y or {x,y} 5 R & x 7 R y Intuitively, the graph of ASH is obtained by placing the graphs of UGH and RH side by side. Jim Sec Mary Sec Jeremy Dean George Chair Lucy Researcher Mike Faculty Sam Faculty CS-Faculty Research Citizens Adm-Staff CS-Dept Research Eng-Dept Research Non-Citizens Employee Public Employee

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, 7 AO ), where 7 AO is defined as follows: x 7 AO y iff {x,y} 5 Obj U T & x 7 OT y or {x,y} 5 R & x 7 R y Intuitively, the graph of AOH is obtained by placing the graphs of OTH and the inverse of RH side by side. jim ed val mom dad sis jim ed val EMPLOYEE Univ Adm-Staff personal Adm-Staff staff Adm-Staff faculty Faculty Mail Secretary accts Dean

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. Authorizations: Propagation Policies G 1 (o, +a) (o, -a) G 2 G5G5 G3G3 G 4 (o,-a) G 6 (o,-a) u1u1 u2u2 R =  AUTH = {(o,G 1,+a), (o,G 2,-a), (o,G 4,-a), (o,G 6,-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. Authorizations: Propagation Policies (cont) No propagation AUTH’ = AUTH [ x U X U Y: (z,+a) U H AUTH’ (x) O (z,+a) U H AUTH (x) (z,-a) U H AUTH’ (x) O (z,-a) U H AUTH (x) G 1 (o, +a) (o, -a) G 2 G5G5 G3G3 G 4 (o,-a) G 6 (o,-a) u1u1 u2u2 R =  AUTH = {(o,G 1,+a), (o,G 2,-a), (o,G 4,-a), (o,G 6,-a)}

18. Authorizations: Propagation Policies (cont) No overriding All authorizations are propagated to the subnodes [ x U X U Y: (z,+a) U H AUTH’ (x) O \ y U X U Y, x 7 y, (z,+a) U H AUTH (y) (z,-a) U H AUTH’ (x) O \ y U X U Y, x 7 y, (z,-a) U H AUTH (y) G 1 (o, +a) (o, -a) G 2 (o,+a) (o,-a) u 1 (o,+a) G 3 (o, +a)G 4 (o,-a) (o,+a) G 6 (o,-a) (o, +a) u 2 (o,-a) (o,+a) R =  AUTH = {(o,G 1,+a), (o,G 2,-a), (o,G 4,-a), (o,G 6,-a)} (o,-a) G 5 (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) U H AUTH’ (x) O \ y, \ w U X U Y, y=w, x 7 y, x 7 w 7 y, (z,+a) U H AUTH (y), (z,-a) U H AUTH (w) [ x U X U Y: (z,-a) U H AUTH’ (x) O \ y, \ w U X U Y, y=w, x 7 y, x 7 w 7 y, (z,-a) U H AUTH (y), (z,+a) U H AUTH (w) G 1 (o, +a) (o, -a) G 2 G 3 (o, +a)G 4 (o,-a) G 6 (o,-a) u 2 (o,-a) R =  AUTH = {(o,G 1,+a), (o,G 2,-a), (o,G 4,-a), (o,G 6,-a)} (o, -a) G 5 (o, -a) u 1

20. 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) U H AUTH’ (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 H AUTH (y), (z,-a) U H AUTH (w) [ x U X U Y: (z,+a) U H AUTH’ (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 H AUTH (y), (z,-a) U H AUTH (w) R =  AUTH = {(o,G 1,+a), (o,G 2,-a), (o,G 4,-a), (o,G 6,-a)} G 1 (o, +a) (o, -a) G 2 G 3 (o, +a)G 4 (o,-a) G 6 (o,-a) u 2 (o,-a) (o, -a) G 5 (o, -a) u 1 (o,+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. Authorizations: Conflict Resolution Policies (cont) Denials take precedence Negative authorizations are always adopted when conflict occurs. For example, using the Path Overrides example: G 1 (o, +a) (o, -a) G 2 G 3 (o, +a)G 4 (o,-a) G 6 (o,-a) u 2 (o,-a) (o, -a) G 5 (o, -a) u 1 (o,+a) G 1 (o, +a) (o, -a) G 2 G 3 (o, +a)G 4 (o,-a) G 6 (o,-a) u 2 (o,-a) (o, -a) G 5 (o, -a) u 1 (o,+a)

23. Authorizations: Conflict Resolution Policies (cont) Permissions take precedence Positive authorizations are always adopted when conflict occurs. For example, using the Path Overrides example: G 1 (o, +a) (o, -a) G 2 G 3 (o, +a)G 4 (o,-a) G 6 (o,-a) u 2 (o,-a) (o, -a) G 5 (o, -a) u 1 (o,+a) G 1 (o, +a) (o, -a) G 2 G 3 (o, +a)G 4 (o,-a) G 6 (o,-a) u 2 (o,-a) (o, -a) G 5 (o, -a) u 1 (o,+a)

24. 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: G 1 (o, +a) (o, -a) G 2 G 3 (o, +a)G 4 (o,-a) G 6 (o,-a) u 2 (o,-a) (o, -a) G 5 (o, -a) u 1 (o,+a) G 1 (o, +a) (o, -a) G 2 G 3 (o, +a)G 4 (o,-a) G 6 (o,-a) u 2 (o,-a) (o, -a) G 5 (o, -a) u 1 (o,+a)

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: V O T is the set of types. Variable: V T U is the set of users. Variable: V U G is the set of groups. Variable: V G R is the set of roles. Variable: V R A is the set of signed actions. Variable: V A SA is the set of unsigned actions. Variable: V SA

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

35. Authorization Specification Strata LevelStratumPredicateRules defining predicate 0AS 0 hie-predicate rel-predicate done Base relations Base relation 1AS 1 candoBody may contain done, hie- and rel- literals 2AS 2 dercandoBody may contain cando, dercando, done, hie-, and rel- literals. Occurrences of dercando literals must be positive 3AS 3 doIn the case when head is of the form do(-,-,+a), body may contain cando, dercando, done, hie- and rel- literals 4AS 4 doIn the case when head is of the form do(-,-,-a), body may contain just one literal !do(o,s,+a) 5AS 5 errorBody may contain do, cando, dercando, done, hie- and rel- literals.

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 AS 2 Decision view is AS 3 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