Relationship-Based Access Control (ReBAC)

Transcription

1 CS 5323 Relationship-Based Access Control (ReBAC) Pro. Ravi Sandhu Executive Director and Endowed Chair Lecture 6 ravi.utsa@gmail.com 1

2 Access Control Fixed policy Discretionary Access Control (DAC), 1970 Mandatory Access Control (MAC), 1970 Role Based Access Control (RBAC), 1995 Flexible policy Attribute Based Access Control (ABAC),???? 2

3 Access Control Fixed policy Discretionary Access Control (DAC), 1970 Mandatory Access Control (MAC), 1970 Relationship Based Access Control (ReBAC), 2008 Role Based Access Control (RBAC), 1995 Flexible policy Attribute Based Access Control (ABAC),???? 3

4 Access Control Fixed policy Discretionary Access Control (DAC), 1970 Mandatory Access Control (MAC), 1970 Relationship Based Access Control (ReBAC), 2008 Role Based Access Control (RBAC), 1995 Flexible policy Attribute Based Access Control (ABAC),???? 4

5 ReBAC Models 5

6 Online Social Networks (OSNs) Social graph is modeled as a directed labeled simple graph G=<U, E, Σ> Nodes U as users Edges E as relationships Σ={σ 1, σ 2,,σ n, σ 1-1, σ 2-1,, σ n -1 } as relationship types supported 6

7 Access Control in OSNs Policy Individualization Users deine their own privacy and activity preerences Related users can conigure policies too Collectively used by the system or control decision User and Resource as a Target e.g., poke, messaging, riendship invitation User Policies or Outgoing and Incoming Actions User can be either requester or target o activity Allows control on 1) activities w/o knowing a particular resource and 2) activities against the user w/o knowing a particular access requestor e.g., block notiication o riend s activities; restrict rom viewing violent contents 7

8 U2U ReBAC (UURAC) Model U A : Accessing User U T : Target User U C : Controlling User R T : Target Resource AUP: Accessing User Policy TUP: Target User Policy TRP: Target Resource Policy SP: System Policy Policy Individualization User and Resource as a Target Separation o user policies or incoming and outgoing actions Regular Expression based path pattern w/ max hopcounts (e.g., <u a, (*c,3)>) 8

9 Access Request and Evaluation Access Request <u a, action, target> u a tries to perorm action on target Target can be either user u t or resource r t Policies and Relationships used or Access Evaluation When u a requests to access a user u t u a s AUP, u t s TUP, SP U2U relationships between u a and u t When u a requests to access a resource r t u a s AUP, r t s TRP, SP U2U relationships between u a and u c 9

10 Policy Representations action -1 in TUP and TRP is the passive orm since it applies to the recipient o action TRP has an extra parameter u c to speciy the controlling user U2U relationships between u a and u c SP does not dierentiate the active and passive orms SP or resource needs r.typename, r.typevalue to reine the scope o the resource 10

11 Example 11

12 Beyond U2U Relationships There are various types o relationships between users and resources in addition to U2U relationships and ownership e.g., share, like, comment, tag, etc U2U, U2R and R2R U2R urther enables relationship and policy administration 12

13 U2U, U2R & R2R ReBAC (URRAC) Model AU: Accessing User AS: Accessing Session TU: Target User TS: Target Session O: Object P: Policy P AU : Accessing User Policy P AS : Accessing Session Policy P TU : Target User Policy P TS : Target Session Policy P O : Object Policy P P : Policy or Policy P Sys : System Policy 13

14 Dierences with UURAC Access Request (s, act, T) where T may contain multiple objects Policy Administration User-session Distinction Hopcount Skipping Local hopcount stated inside [[]] will not be counted in global hopcount. E.g., ([*,3][[c*, 2]],3), the local hopcount 2 or c* does not apply to the global hopcount 3, thus allowing * to have up to 3 hops. 14

15 Policy Conlict Resolution System-deined conlict resolution or potential conlicts among user-speciied policies Disjunctive, conjunctive and prioritized order between relationship types <share-1, (own tag share)> <read-1, (own tag)> <riend_request, (parent 15

16 Beyond Relationships ReBAC usually relies on type, depth, or strength o relationships, but cannot express more complicated topological inormation ReBAC lacks support or attributes o users, resources, and relationships Useul examples include common riends, duration o riendship, minimum age, etc. 16

17 Attribute-based Policy <quantiier, (ATTR(N), ATTR(E)), count i> [+1, -2], age(u) > 18 [+1, -1], weight(e) > 0.5 {+1, +2, -1}, gender(u) = male 17

18 Attribute-based Policy Node attributes Deine user s identity and characteristics: e.g., name, age, gender, etc. Edge attributes Describe the characteristics o the relationship: e.g., weight, type, duration, etc. Count attributes Occurrence requirements or the attribute-based path speciication, speciying the minimum 18

19 Example: No Attributes Bob Dave Alice Ed Harry Carol Fred Georg e 19

20 Example: Node Attributes Bob Occupation = student Dave Occupation = student Alice Ed Occupation = teacher Harry Carol Occupation = student Fred Occupation = teacher Georg e Occupation = student <access, (u a, ((*, 4): [+1, -1], occupation = student, count 3)))> 20

21 Example: Edge Attributes Since = Feb, 2014 Since = June, 2013 Bob Dave Since = Aug, 2008 Alice Ed Since = May, 2009 Harry Since = Aug, 2010 Carol Fred Georg e <read, Photo1, (u a, ((*, 3): [+1, -1], duration 3 month, _)))> 21

22 ReBAC Models Object-to-Object 22

23 Object Relationships in ReBAC ReBAC or OSN generally considers only user to user relationship OSN has very speciic types o resources photos, notes, comments, which are strongly tied to users. Even though some ReBAC models consider general computing systems beyond OSNs they still need users/subjects existence in relationship graph. 23

24 ReBAC in General Beyond OSNs Participant-o user 1 project 1 Participant-o older 1 Supervises Member-o doc 1 Member-o older 2 doc 2 Member-o A sample Relationship Graph or Organizational Environment [RPPM, Crampton et al.,2014 ] 24

25 Existence o Object Relationship Independent o User Object Relationship in Object Oriented System (Inheritance, Composition and Association) History o a Git Project (Version Control System) is a DAG 25

26 Limitations o Existing ReBAC Models Cannot conigure relationship between objects independent o user. Cannot express authorization policy solely considering object relationship. 26

27 How the model would look like? Object to Object Relationship Based Access Control Policy Level Example ACL(o 1 ) = {u 1 } ACL(o 2 ) = {} ACL(o 3 ) = {u 2 } policylevel(a 1,o 1 ) =2 policylevel(a 2,o 1 ) =0 policylevel(a 1,o 2 ) =1 policylevel(a 2,o 2 ) =0 policylevel(a 1,o 3 ) =3 policylevel(a 2,o 3 ) =2 policylevel(a 1,o 4 ) =2 policylevel(a 2,o 4 ) =0 27

28 OOReBAC: Model Components and Deinition 28

29 OOReBAC: An Example Sequence o operations and its outcome: Coniguration: Sequence o operations and its outcome: 29

30 OOReBAC: Application An OOReBAC Instantiation Sequence o Operations and Outcomes 30

31 ABAC-ReBAC Comparison 31

32 ReBAC Vs. ABAC ReBAC? ABAC Are they Comparable? Can Attributes Express Relationships? Can ReBAC Conigure ABAC? Vice versa? Do they have equal expressive power? I not Which one is more expressive? 32

33 Attribute Types 1. Attribute Value Structure Atomic-valued or Single-valued Attribute (e.g. gender) Set-valued or Multi-valued Attribute (e.g. phonenumber) Structured Attribute (e.g person-ino (name, age, phonenumber )) 2. Attribute Value Scope Entity Attribute (e.g. riend) Non-entity Attribute (e.g. age) 3. Boundedness o attribute range Finite Domain Attribute (e.g. gender) Ininite Domain Attribute (e.g. time) 4. Attribute association Contextual or Environmental Attribute (e.g. currenttime) Meta Attribute (e.g. role(user) = manager, task(manager) = supervise) 5. Attribute mutability Mutable Attribute Immutable Attribute 33

34 Attribute Function Composition 34

35 Assumptions All non entity attribute are inite domain Entity attribute unctions are partial unctions deined on existing entities only Inner attribute unction in an attribute unction composition should always be entity attributes Structured attribute is a multivalued tuple o atomic or set-valued attributes. So it is more expressive than atomic or set-valued attribute. 35

36 ReBAC Classiication Figure 3.: ReBAC Framework 36

37 Example Figure 4.: A Simple Relationship Graph Expressible in ReBAC B [Crampton et al ] 37

38 Example (Continued ) Figure 5: An Example o Node Attributes in Relationship Graph Expressible in ReBAC BN Figure 6: An Example o Edge Attributes in Relationship Graph Expressible in ReBAC BE 38

39 Example (Continued ) Structure Edge Attribute: dependson Sub Attributes o dependson Source Node Target Node RelationshipType dependson (u,r,ua) = (y,x,tt) Figure 7: An Example o Node Attributes in Relationship Graph Expressible in ReBAC BNES [Cheng et al. 2016] 39

40 ABAC Classiication Figure 8: ABAC Framework 40

41 Expressing Relationship Graph with Attributes Entity types = {user, project, ile, directory} Attributes: User attributes ={Participant-o, Supervises} File attributes = {Resource-or, FileMember-o} Project attributes = {} Directory attributes ={DirectoryMember-o} Relationship Graph in Figure 4 is Expressible with ABAC E 41

42 Expressing Relationship Graph with Attributes (Continued ) entitytype = {user} Attribute: user s entity attribute ={riend} User s Non Entity Attribute ={Name, Age, Gender} Relationship Graph in Figure 5 is Expressible with ABAC E Relationship Graph in Figure 6 is Expressible with ABAC ES entitytype = {user, project, tenant} Attribute: user s atomic entity attribute ={supervises} User s structured entity Attribute ={assignedby} e.g. assignedby(bob) = ( Project1, supervises, Alice ) 42

43 Expressing Relationship Graph with Attributes (Continued ) Entity types: {user, tenant, role} Attribute: User s atomic entity attribute: {UO,UA} Users Structured Entity Attribute: {dependentedge} dependentedge(u) = ( r, UA, {(y,x,tt)} ) Relationship Graph in Figure 7 is Expressible with ABAC ES 43

44 Expressing Multilevel Relationship With Attributes riend riend Alice Bob Carol Figure 9. A simple Relationship Graph Attribute Composition Needs one attribute: riend Policy Expression uses Attribute composition riend(alice)={bob} riend(riend(alice))={carol} Composite Attribute Needs two attribute 1. riend 2. riendoriend Policy Expression uses direct attributes riend(alice) ={Bob} riendoriend(alice)={carol} 44

45 Example: riend riend(alice) = {Amy, Carol} riendoriend(alice) = {John} Figure 10. A simple Relationship Graph I the riend relationship between Amy and John deleted riendoriend(alice) =? Instead o keeping the end user as attribute value we have to keep the exact path inormation. 45

46 Example Figure 12: Multilevel Relationship Expression with Attribute 46

47 Comparison: On Dynamics Figure 12: ReBAC Dynamics, ABAC Dynamics and Attribute Domain wise Comparison between ReBAC and ABAC 47

48 Comparison: Equivalent Structural Models or ReBAC and ABAC Figure 13: Equivalence o ReBAC and ABAC Structural Classiication 48

49 Comparison: Non-Equivalent Structural models or ReBAC and ABAC Figure 14: Non-Equivalence o ReBAC and ABAC Structural Classiication 49

50 Comparison: On Perormance Attribute Composition is similar to ReBAC and Both have polynomial complexity or authorization policy and constant complexity on update Composite attribute has constant complexity on authorization policy and polynomial complexity on update to maintain relationship changes. Perormance Depends on : Node Dynamics Relationship Dynamics Density o the Relationship Graph 50

51 Comparison: Choice o Models For static system or only change or non entity attribute------composite attribute is the best approach System with huge node dynamics, relationship dynamics and high relationship density----- Attribute composition is the best option I the system is in the middle between two extremes ---- A hybrid approach where both composite attribute and attribute composition is used. Hybrid Approach: To achieve p level relationship composition it uses m level composite attribute and n level attribute composition where p = n X m. 51

52 Comparison: In Respect o PEI Framework No Dierence Both the approaches dier here Figure 15: PEI Framework 52