Changes between Version 10 and Version 11 of TIEDCredentials


Ignore:
Timestamp:
04/19/13 19:21:09 (11 years ago)
Author:
faber@isi.edu
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • TIEDCredentials

    v10 v11  
    5959For a given request at an Aggregate Manager, the Manager knows the principal making the request, the target of the request, and which privilege is required to execute it.  It has a prover initialized with its policy (an ABAC context in [http://abac.deterlab.net libabac] terms).  It adds any credentials in the request and asks the prover a yes/no question - "does the principal making this request have the proper privilege?"
    6060
    61 The first thing to encode in ABAC is "the proper privilege."  The ABAC attribute {{{AM.privilege(Target)}}} means that AM believes principals in that set have privilege with respect to Target.  For example, the resolve on a slice S would be {{{AM.resolve(S)}}}.  When a principal (P) requests an operation that requires resolve rights on slice S, the Manager (AM) asks the prover if P is a member of {{{AM.resolve(S)}}} (or in other words, if P has the {{{AM.resolve(S)}}} attribute).
     61The first thing to encode in ABAC is "the proper privilege."  The ABAC attribute {{{AM.privilege(Target)}}} means that AM believes principals in that set have privilege with respect to Target.  For example, the privilege to issue resolve on a slice S would be the ABAC attribute/set {{{AM.resolve(S)}}}.  When a principal (P) requests an operation that requires resolve rights on slice S, the Manager (AM) asks the prover if P is a member of {{{AM.resolve(S)}}} (or in other words, if P has the attribute {{{AM.resolve(S)}}} attribute).
    6262
    63 Aggregate Managers do not issue these credentials to users.  They are elements of the local policy, encoded in a configuration file. While ABAC allows delegation here, for now lets assume a series of simple delegations.  There are a set of issuers that each Aggregate Manager believes.  For each Issuer that AM believes, it has a rule like this:
     63Aggregate Managers do not issue credentials conferring {{{AM.privilege()}}} to users.  They are inferred from ABAC rules  in the local policy, encoded in a configuration file. While ABAC allows delegation here, for now we assume a series of simple delegations.  There are a set of issuers that each Aggregate Manager believes.  For each Issuer that AM believes, it has a rule like this:
    6464
    6565{{{
    … …  
    7777Issuers, such as Slice Authorities and Clearinghoses, issue credentials to users.  Here we describe how libabac will translate a credential into multiple ABAC statements inside the prover.
    7878
    79 Because GENI allows all privileges to be passed around by "speaks-for" the ABAC for issuing a privilege to a user (P) looks like:
     79Because GENI allows all privileges to be transferred around by "speaks-for" the ABAC translation of a credential issuing a privilege to a user (P) looks like:
    8080
    8181{{{
    … …  
    8787The Issuer says that anyone that speaks for P has the privilege.  The Issuer says P speaks for itself.  The Issuer says that anyone P says speaks for P speaks for P.  When an Issuer hands out a GENI credential assigning {{{privilege}}} with respect to Target, it is making those three statements in ABAC.  The first line is repeated for each privilege in the credential; the last two are added to the prover once per credential.
    8888
    89 When a user (P) issues a speaks-for credential for a tool (T), that credential encodes the following ABAC rule:
     89When a user (P) issues a speaks-for credential for a tool (T), that credential is translated into ABAC as:
    9090
    9191{{{
    … …  
    9393}}}
    9494
    95 Note that this interprets the same credential format (GENI privilege credential) differently depending on the privilege being assigned (speaks-for).  This is because of the implicit semantics of "speaks-for" buried in its definition.
     95Note that this interprets the same credential format (GENI privilege credential) differently depending on the privilege being assigned (speaks-for).  This is because of the implicit semantics of "speaks-for" buried in its definition.  "Speaks-for" can affect any credential, so it permeates the policy.  One way to see this is to note that speaks_for appears on the right side of rules generated for all other privileges.
    9696
    97 To be concrete: if (in GENI terms) AM trusts Issuer about {{{resolve}}} on {{{Target}}}, Issuer has handed P a GENI credential assigning {{{resolve}}} on {{{Target}}}, and P has issued a "speaks-for" credential to tool T, and T makes a request including both credentials, AM has the following ABAC rules in its prover:
     97To be concrete: if (in GENI terms)
     98 * AM trusts Issuer about {{{resolve}}} on {{{Target}}}
     99 * Issuer has handed P a GENI credential assigning {{{resolve}}} on {{{Target}}}
     100 * P has issued a "speaks-for" credential to tool T
     101 * T makes a request including both credentials
     102
     103AM has the following ABAC rules in its prover:
    98104
    99105{{{