Changes between Version 1 and Version 2 of TIEDABACModel


Ignore:
Timestamp:
07/12/09 20:03:08 (15 years ago)
Author:
faber@isi.edu
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • TIEDABACModel

    v1 v2  
    1 = ABAC Authorization Control Illustrative Example =
     1= ABAC Authorization Control Model and Discussion =
    22
    3 ABAC is an attribute-based authorization system that combines attributes using a simple reasoning system to provide authorization that
     3== Why ABAC? ==
     4
     5[http://www.isso.sparta.com/research_projects/security_infrastructure/abac_overview.html ABAC] is an attribute-based authorization system that combines attributes using a simple reasoning system to provide authorization that
    46 * Expresses delegation and other authorization models efficiently and scalably
    57 * Allows access requesters and granters to control how much information they reveal
    … …  
    99101
    100102When possible binding to a public-key-based identifier is infinitely preferred.
    101 
    102 == An Example ==
    103 
    104 === Scenario ===
    105 
    106 Consider the ACM using GENI to run a contest like the University of [http://ictf.cs.ucsb.edu/ Santa Barbara International Capture the Flag Contest] on a larger scale.  The plan is for security experts from several universities to configure a large network of machines as a playground for intrusion testers.  A slice will be created containing many (virtual) machines that will be configured with a variety of known shortcomings.  Signed data is hidden in various places on the machines.  Then players from many universities - in fact many players from across the country - are granted access to the slice and a scavenger hunt ensues.  The team that most completely audits the security of the network, by capturning the most sensitive data, wins.  There may be other scoring.
    107 
    108 There are two classes of princpals that will be requesting access to GENI resources for this contest.  There will be a comparatively small number of officials that will need allocation and configuration rights to the slice in order to set up and administer the game.  There will also be the thousands or more contestants who will need access to the slice, but not configuration rights.  Because of the large number of contestants, the ACM does not want to be directly in charge of vetting each one.  Individual universities (and perhaps other sites) will be able to decide on the criteria to admit players from their institutions independently.  Should anything go amiss - or any kind of cheating be detected - officials will want to know where the contestent came from and how they were admitted.
    109 
    110 ACM is deliberately vague about qualifications for participation.  Some universities may choose to make the contest open to any student at the university, or to any student in the local chapter of the ACM.  Others may restrict participation to students enrolled in a prerequisite class.  ACM delegates this decision by designating authorizers at each university.
    111 
    112 === ABAC Encoding (simple delegation) ===
    113 
    114 For the purposes of the example, we assume that there is a GENI principal that has allocated an empty slice for the contest.  That slice will be expanded and configured by principals with the GENI.adminCTF attribute and accessible by players with the GENI.accessCTF attribute.  We now lay out the attribute policies for allocating these two attributes.
    115 
    116 Because the set of officials is small, the ACM chooses to administer them directly.  To support this the GENI principal delegates the adminCTF attribute to the ACM principal:
    117 
    118 [[Image(example1.png)]]
    119 
    120 And the ACM principal authorizes principals by making them officials.
    121 
    122 [[Image(example2.png)]]
    123 
    124 The ACM principal can add or delete officials independently, and those officials have admin rights to the slice automatically.
    125 
    126 Of course, both the ACM and GENI will be assigning other attributes unrelated to this project, so their attribute space may be large enough that we provide a tool to maintain these spaces and their ramifications.  Most of the images in this section are screenshots from that application.  The image below is the result of a query for all users with the GENI.CTFadmin attributes from a set of attributes that includes those above.  The two above are only the local attribute spaces of the two principals, below is a summary of both.  (Principals who have the attribute are flagged by the bold red border, though all principals in this case have the rights).
    127 
    128 [[Image(example3.png)]]
    129 
    130 === ABAC Encoding (linked roles) ===
    131 
    132 Because there are many more contestants than officials and the qualifying requirements are locally decided, the access rights to the contest slice are administered more loosely.  This time GENI delegates access to the principals that ACM's CTFreps designate as contestants.
    133 
    134 [[Image(example4.png)]]
    135 
    136 ACM now selects principals at each participating university that can authorize contestants (CTFreps).
    137 
    138 [[Image(example5.png)]]
    139 
    140 The USC principal selects students individually:
    141 
    142 [[Image(example6.png)]]
    143 
    144 The MIT principal opens the contest to all MIT students:
    145 
    146 [[Image(example7.png)]]
    147 
    148 And the UCLA principal further delegates the authority to its local ACM officers:
    149 
    150 [[Image(example8.png)]]
    151 
    152 Those officers then select individual students:
    153 
    154 [[Image(example9.png)]]
    155 
    156 These local decisions make for a rich global attribute derivation graph.  As before determining which principals can access the graph is done by a depth first search through the graph.
    157 
    158 [[Image(example10.png)]]
    159 
    160 === Negotiating Access ===
    161 
    162 While the global graph is somewhat daunting in its complexity, it is important to realize that any single access decision requires the construction of only one path from principal to attribute.  The two endpoints construct a graph together from their credentials, each of which represents an edge in the visualization above.  For example, the case where faber is authenticating to the slice requires proving that faber has the GENI.CTFadmin credential.  The slice has the following relevant credential:
    163 
    164 [[Image(example1.png)]]
    165 
    166 And faber holds:
    167 
    168 [[Image(example11.png)]]
    169 
    170 The simplest exchange is that faber requests access, the slice sends its relevant credential as a starting graph and faber responds with the completed graph:
    171 
    172 [[Image(example12.png)]]
    173 
    174 Each side can check all the credentials to make sure the reasoning is sound.  The credentials only fit together one way so they agree on the proof.  At that point the authorization is complete.
    175 
    176 If the environment is open, the GENI principal can simply publish the relevant credential for CTF slice admin (and general) access.  Because each requester now knows the beginning of the graph, they are likely to be able to include the whole proof in their first request, removing a round trip time.
    177 
    178 In addition, the completed graph completely reflects the decisions made to grant or deny access.  These can be logged as expressive audit trials covering both the decisions and the reasons for those decisions.
    179 
    180 === Conclusions ===
    181 
    182 This example has illustrated some of the key features of ABAC that make it scalable to operate and decentralized to administer while being practical to negotiate access.