Changes between Version 3 and Version 4 of FeddAuthorizationArchitecture

Timestamp:

Oct 20, 2009 6:30:38 PM (14 years ago)

Author:

faber

Comment:

--

FeddAuthorizationArchitecture

@@ -104 +104 @@
 Researchers and the controllers are obvious cases of entities that need to be principals.  In the simplest understanding of operating on experiments, those are the entities that talk to one another.
 
-Making the experiment itself a principal creates an important point of delegation.
+Making the experiment itself a principal creates an important point of delegation, as we shall see below.
+
+Adding the third parties considerably enriches the kinds of authorization available.
+
+=== Mapping Local Access Control Mechanisms into Attributes ===
+
+Local testbeds will have different mechanisms for local access control that are tunded to their model of experimentation, or perhaps remain as a vestige of earlier systems.  Local systems may use local identities or groups as Emulab does or have identities with explicit access control lists as many file systems or web services do.  Other choices are certainly valid.  The diffciulty arises in converting these local systems into ABAC attributes to be proven.
+
+To some extent this mapping is unavoidably a matter of local testbed policy.  The semantics of the particular local groups, identities, or access control lists will depend on their application to local testbed resources.  The basic procedure is twofold: create a set of ABAC attributes in the local testbed principal's name space that reflect the access control classes relevant to federated use, and determine the attributes in the relevant other principals' name spaces that are acceptable.
+
+The first setp is a farily straightforward translation of local authorization policy into the larger name space.  The second is the setting of policy for federated authorization.  For example, an emulab that allows federated users to instantiate sub-experiments under one of three groups (with access to different local resources) will translate those group names into ABAC attributes.  Determining how to map a given user into one of those groups is done by setting ABAC credentials that define the reasoning for assigning a user to a local group.  For example all users with a {{{CERTIFIED.user}}} attribute could be mapped to the local {{{certified}}} group, though there could be a variety of (ABAC-expressible) ways that a user could be delegated a {{{CERTIFIED.user}}} attribute.
+
+The versatility presents some problems.  A user may map into more than one local authorization class, and the classes will likely not have the same ability to allocate resources.  When a request is made, the testbed's access controller will begin by asking the requester to prove one or more attributes, but the selection requires some thought.
+
+If the local access control classes are a strict containment hierarchy, the access controller can ask the requester to prove the attributes in order from highest to lowest.  This divorces the authorization request from the specific allocation request, but may result in a requester revealing more about its capabilities than absolutely necessary (or being granted more local access power than is strictly necessary).
+
+Alternatively, the access controller can map the request into local resources, determine from the local access controller what credentials would be sufficient to access those resources in the local testbed, and the authorization controller can map those into the set of ABAC attributes that would allow the access.  This requires something of a blurring of the lines between access controller and authorization controller, but results in a more focused set of authorization decisions.  Not every local authorization system will be able to accomplish the reverse mapping.  It is worth noting that this approach also reveals more about the local access control policy.
+
+The fundamental tradeoff between revealing information to the requester and the requester revealing information to the access controller is difficult to sidestep.  Similarly different testbeds will make different decisions about what to reveal, and it is a power of the ABAC system that such a spectrum is possible.
+
+The more fine-grained and unstructured the local access control and the more different types of resources available in a testbed the more difficult the mapping into ABAC is.  We believe that local resource allocation on of such testbeds is also complex, and one cannot expect federating to simplify such allocation.