Changes between Version 13 and Version 14 of TIEDCredentials


Ignore:
Timestamp:
04/22/13 13:44:14 (11 years ago)
Author:
faber@isi.edu
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TIEDCredentials

    v13 v14  
    55GENI is currently working toward making [wiki:TIEDABACModel ABAC] the primary authorization system for the [wiki:GAPI_AM_API GENI AM API]. A first step in that direction is to use the ABAC prover library, [http://abac.deterlab.net libabac], to make authorization decisions based on the current GENI policy.  A first step in this direction is to implement current GENI policy - including a new "speaks-for" feature - using ABAC without changing the existing AM API calls or credential formats.  This document describes our approach to do so.  While there are other issues to consider, for example improving libabac portability, this document does not address them.
    66
    7 Current GENI credentials allow one principal to grant privileges to other principals.  If the original granting principal allows it, privileges can be further delegated.
     7[GeniApiCredentials Current GENI credentials] allow one principal to grant privileges to other principals.  If the original granting principal allows it, privileges can be further delegated.
    88
    99The "speaks-for" privilege is a new privilege intended to be used as follows. A user wishes to use a tool to access aggregate managers but does not want to give its identity certificate and private key to that tool, which may be a web service.  The user can issue a GENI credential granting a "speaks-for" right to the tool (a principal).  The tool includes that credential in its requests and the aggregate manager (and other parties making authorization decisions) will treat these requests as though they came from the user.
     
    1515 * A tool need not receive and manipulate all the delegated credentials.  (For example, a tool need not have all of a user's slice credentials to look up the status of all the user's slices.)
    1616
    17 "Speaks-for" makes all existing GENI credentials delegatable by "speaks-for".  To make future credentials immune to this delegation will require a format change to the GENI credentials.  It is unclear to me if "speaks-for" permits delegation as well, but the rest of this document assumes that it does.
     17== Speaks-for and Delegation ==
     18
     19As described, it seems that "speaks-for" makes all existing GENI credentials delegatable by "speaks-for".  That is once a tool "speaks-for" a user, that tool should be able to delegate privileges on behalf of that user.  The current credential format seems to make such an action inexpressible.  We may want to disallow it to keep the speaks-for and delegation mechanisms distinct.
     20
     21The [GeniApiCredentials GENI credential format] has a mundane reason a delegation by a tool is currently impossible.  A principal delegates a privilege by creating a new credential that includes the credential that granted the privilege being delegated.  The credential says, "here's my delegation of the privilege and a credential showing I had the privilege and right to delegate it."  When a tool acting for a principal wants to do a delegation, it would have to include both the credential conferring the privilege being delegated and the credential conferring the privilege to "speak-for" the holder of that credential.  There is only one field in the credential.  Of course, future formats simply add a field for the speaks-for credential(s?).
     22
     23It is worth thinking about whether that change is useful.  On the one hand, a "speaks-for" notion that allows a tool to do everything a user can do is clean and elegant.  On the other, trusting a tool to act on (and acquire) resources on a user's behalf seems different from trusting a tool to to act on (and acquire) resources on a user's behalf and to delegate authority on the user's behalf.
     24
     25The ABAC prover will support either choice.  The current state of affairs is that a tool operating under speaks-for cannot delegate privileges.
     26
     27== ABAC authorization in GENI ==
    1828
    1929When ABAC authorization code is integrated, the workflow is unchanged for most elements in the system.  Users, clearinghouses, and slice authorities generate the same credentials they would otherwise.  The workflow change for any element that makes an access check based on GENI privilege credentials, for example an aggregate manager, is that when it receives a request through the [wiki:GAPI_AM_API GENI AM API] it will
     
    124134{{{
    125135Issuer.privilege(Target) <- Issuer.can_delegate_privilege(Target).privilege(Target)
    126 Issuer.can_delegate_privilege(Target) <- Issuer.speaks_for(P)
    127 }}}
    128 
    129 The issuer says that anyone in the {{{Issuer.can_delegate_privilege(Target)}}} set can assign {{{Issuer.privilege(Target)}}} and that any principal who speaks for P (including P) is in that set.  This formulation implies that "speaks-for" works for delegation as well.  A tool that can speak for a user can delegate on that user's behalf.  If the second line is:
    130 
    131 {{{
    132136Issuer.can_delegate_privilege(Target) <- P
    133137}}}
    134138
    135 then only the user can delegate.
     139The second line restricts delegation to the principal to whom the credential was issued, as current formats imply.
     140If we add "speaks-for" delegation, i.e., a tool that can speak for a user can delegate on that user's behalf,  If the second line is:
     141
     142{{{
     143Issuer.can_delegate_privilege(Target) <- P.speaks_for(P)
     144}}}
     145
     146The issuer says that anyone in the {{{Issuer.can_delegate_privilege(Target)}}} set can assign {{{Issuer.privilege(Target)}}} and that any principal who speaks for P (including P) is in that set.
    136147
    137148== RT1-lite templates for AMs ==