Changes between Version 17 and Version 18 of TIEDABACDemo
- Timestamp:
- 07/10/09 20:31:04 (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TIEDABACDemo
v17 v18 11 11 ABAC facilitates authorization decisions by providing rules under which actors in the system, called principals, prove that they have certain attributes necessary for accessing resources. Which attributes are required for a given resource is a matter of policy outside the system. ABAC can represent delegation of various forms in scalable and separable ways that can be reasoned about formally. This section sketches the ideas behind ABAC. More information is available in [http://www.isso.sparta.com/research_projects/security_infrastructure/abac_overview.html#docs the literature ]. 12 12 13 In ABAC, principals are created by authenticating to the system. A principalcan be an individual (researcher, user) or larger authority (GPO, university). Prinicpals can use a range of systems to authenticate themselves. A principal can be the subject of authorization decisions and have attributes asserted about it by other principals.13 In ABAC, principals can be an individual (researcher, user) or larger authority (GPO, university). Prinicpals can use a range of systems to authenticate themselves. A principal can be the subject of authorization decisions and have attributes asserted about it by other principals. 14 14 15 An attribute is a n assertion by one principal that another has a given property. The University of Southern California (a principal) may assert that Ted Faber (a principal) is a staff member (attribute). The attributes are scoped by prinicpal. This is represented as a digitally signed assertion.15 An attribute is a property of a principal created by the assertion of another princppal. The University of Southern California (a principal) may assert that Ted Faber (a principal) is a staff member (attribute). The attributes are scoped by prinicpal, that is if USC asserts Ted Faber is staff, that is one attribute, if ISI also asserts that Ted Faber is staff that is a second attribute. Assertions are represented as a digitally signed statement, called a credential. 16 16 17 17 A given prinicpal may also assert rules about how attributes relate. The GPO may assert that all USC GENI staff are also GPO prototypers. That delegates authority to USC add to GPO prototypers. In this case the delegated attribute (GPO prototypers) is given to prinicpals who also possess the delegating attribute (ISI GENI). … … 21 21 In this case, the delegated attribute (GPO GENI user) is delegated to principals who possess a one (or more) of a set of attributes (''P'' GENI user for many ''P''). That set is defined in terms of an authorizer attribute (NSF PI). Any principal with the authorizer attribute can assign the delegated attribute by assigning their local version of the delegating attribute (''P'' GENI user where ''P'' has the NSF PI attribute). This links the authorizer attribute to the delegating attributes, and is often called a linked attribute. 22 22 23 It also points out that each of these delegations maps into an ABAC credential: an a signed assertion that can be used in a proof. Because each of these is a signed assertion of a fact or delegation of authority, connecting them in followinfthe rules above corresponds to collecting those signed credentials, which establishes a trust relationship. ABAC credentials allow principals to negotiate directly about what they consider adequate proof. Below we show a simple visualization that represents constructing that proof as finding a path between two nodes in a graph; the actual negotiation protocol can be similarly simple.23 Each of these delegations is expressed as an ABAC credential: an a signed assertion that can be used in a proof. Because each of these is a signed assertion of a fact or delegation of authority, connecting them in following the rules above corresponds to collecting those signed credentials, which establishes a trust relationship. ABAC credentials allow principals to negotiate directly about what they consider adequate proof. Below we show a simple visualization that represents constructing that proof as finding a path between two nodes in a graph; the actual negotiation protocol can be similarly simple. 24 24 25 25 Until an authorization decision needs to be made, all of these credentials can be kept locally and brought together to make the decision. Principals can also pass them around so they are available when needed. For example, when the NSF designates a PI, it may send that PI the signed attribute so that the PI can use it in authorization requests. … … 33 33 Principals are represented as circles. Our principals are labeled with simple, human-readable names, but in reality the assertions being made are being made about their globally unique identifiers. Those IDs are essentially a public key that identifies the principal (though some systems like Kerberos may have a more intricate implementation). Tools, including ours, represent principals using a readable name, but that's to help users of those tools. 34 34 35 Attributes are a rectangle containing the principal that asserts the attribute and the attribute name in dotted notation. The '''ISI.GENI'''attribute means that the ISI principal is asserting a GENI attribute. Again, ISI is shorthand for that principal's unique identifier, but the attribute names are simple strings.35 Attributes are a rectangle containing the principal that asserts the attribute and the attribute name in dotted notation. The ISI.GENI attribute means that the ISI principal is asserting a GENI attribute. Again, ISI is shorthand for that principal's unique identifier, but the attribute names are simple strings. 36 36 37 The arrow connecting an attribute to a principal indicates that the principal has the attribute. We point the arro r toward the attribute, indicating that the principal is in the group. The presence of such an arrorindicates that the principal controlling the attribute has issued a signed assertion that the other principal has the given attribute. In the example ISI has issued an assertion that Ted is in ISI.GENI.37 The arrow connecting an attribute to a principal indicates that the principal has the attribute. We point the arrow toward the attribute, indicating that the principal is in the group. The presence of such an arrow indicates that the principal controlling the attribute has issued a signed assertion that the other principal has the given attribute. In the example ISI has issued an assertion that Ted is in ISI.GENI. 38 38 39 39 [[Image(Simple.png)]] … … 61 61 In the examples above, creating the paths from principal to attribute that constitute a proof are all done assuming total information in the hands of the prover. ABAC does not require a prover to hold all such information initally and provides a negotiation protocol to gather it. We sketch that protocol here. 62 62 63 Getting access from an ABAC controller consists of constructing a proof that the requesting principal has a given attribute. The two endpoints provide parts of the graph to one another until they have constructed a graph using the rules above that contains such a path. Because edges define node-edge-node sequences in graphs, the building of graphs is an exchange of credentials.63 Getting access from an ABAC controller consists of constructing a proof that the requesting principal has a given attribute. The two endpoints provide parts of the graph to one another until they have constructed a graph using the rules above that contains such a path. Because credentials define node-edge-node sequences in graphs, the building of graphs is an exchange of credentials. 64 64 65 65 As a simple case, consider creating a graph for the linked role example above. Initially TED has two credentials one signed by ISI indicating that TED has the ISI.GENI attribute and one signed by NSF indicating that ISI has the NSF.funded attribute. The GPO has a single credential signed by itself stating that principals who have the NSF.funded attribute are delegated the power to assign the GPO.demo attribute by assigning their local GENI attribute. … … 108 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 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 CAM. Others may restrict participation to students enrolled in a prerequisite class. ACM delegates this decision by designating authorizers at each university.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 111 112 112 === ABAC Encoding (simple delegation) ===