Changes between Version 4 and Version 5 of TIEDABACDemo

Timestamp:

07/10/09 14:26:37 (15 years ago)

Author:

faber@isi.edu

Comment:

--

TIEDABACDemo

@@ -13 +13 @@
 An attribute is an 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.
 
-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.
+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).
 
 Finally, a principal may delegate at one remove.  The GPO may assert that any NSF PI (any principal that the NSF has asserted a PI attribute about) can designate a principal as a GENI user and that user will be a GPO GENI user.  The NSF can affect GPO GENI users by creating or deleting PIs; that is, by adding or removing assertions that a particular principal is a PI.  Individual PIs can also directly designate local GENI users that are also GPO GENI users as above.
 
-Until an authorization decision needs to be made, all of these attributes (signed assertions) can be kept locally and brogght 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.
+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.
+
+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 followinf 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.
+
+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.
 
 === Visualizing ABAC Attributes ===
@@ -37 +41 @@
 [[Image(Creds.png)]]
 
-The image above shows how to walk the chain of attribute assignments and delegations to prove a principal has a given attribute.  In this case, it shows that Ted has the GOP.demo attribute.  It also points out that each arrow maps into an ABAC credential: an element that can be used in a proof.  Because each of these is a signed assertion of a fact or delegation of authority, walking the arrows to an attribute corresponds to collecting those signed credentials, which establishes a trust relationship.  ABAC credentials allow principals to negotiate directly about what they consider adequate proof.
+The image above shows how to walk the chain of attribute assignments and delegations to prove a principal has a given attribute.  In this case, it shows that Ted has the GOP.demo attribute.  Proving a principal has an attribute is equivalent to finding a path from principal to attribute in the graph induced above.  We use this representation in our configuration and visualization tool to help administrators.
+
+[[Image(Linked.png)]]
+
+A linked role is specified by a different attribute that links the authorizing attribute (in parens) to the delegating attribute by a dot, and the arrow completes the delegation.
+
+[[Image(LinkedCreds.png)]]