= GENI-Compatible ABAC credentials =

GENI is currently working toward making [wiki:TIEDABACModel ABAC] the primary authorization system for the [wiki:GAPI_AM_API GENI AM]. A first step in that direction is to implement a credential format compatible with existing [GeniApiCredentials GENI credentials] that can be passed into AM calls and that can be used to implement the "speaks-for" relation.  Though importing ABAC into GENI also requires portability improvements to [http://abac.deterlab.net libabac], this page addresses the credential issues.

"Speaks-for" allows a user to delegate to a tool the right to act on their behalf without giving the tool direct access to the user's [GeniApiIdentifiers GENI identity].

[GeniApiCredentials Existing GENI credential] formats do not allow the full expressiveness of ABAC, but they have two very useful features:

 * The privilege assignment that they express can be written in ABAC
 * They include a type field that can be used to extend them to express more ABAC statements

Our initial plan is to pass credentials in the existing GENI credential format between entities and to import those statements into the ABAC prover at relying parties.  That prover will be used to make the authorization decision.

Encoding the policies may require more expressive ABAC rules than a GENI credential can encode.  In the very short term, we can use the X.509 based formats to encode those more complex ABAC rules.  In very short order we will define types of the existing credential formats to encode these rules.

The rest of this page discusses the short term modifications to libabac that will be needed to support the existing GENI credentials.

== GENI "privilege" credentials ==

The only type of GENI credential currently in use is the "privilege" credential.  This credential assigns a principal (called the owner) one or more privileges with respect to another principal (called the target).  The credential has an implicit issuer, the signer of the credential.  The privileges are strings meaningful to the implementation.  There is also a bit that allows delegation of the privilege.  This section describes how to represent the semantics of the GENI credentials in ABAC statements.  Libabac will import a GENI credential into ABAC statements internally and use those statements to make authorization decisions; the AM (relying party) will import the credentials and policy into libabac and ask libabac for the authorization decision.

The AM is trying to prove that the Owner who is asking to exercise a privilege on Target is authorized with respect to the AM. 

Each GENI credential directly translates into one or more ABAC statements. In the simplest case, each of these statements assigns the owner a privilege with respect to the Target according to the issuer. In ABAC RT1 notation this is 

{{{
Issuer.privilege(Target) <- Owner
}}} 

for each privilege in the credential.  This can be expressed in [http://groups.geni.net/geni/attachment/wiki/GEC11Authorization/chase-abac-gec11.ppt "RT0 lite"] as:

{{{
Issuer.privilege_Target <- Owner
}}} 


Each privilege has a flag indicating whether the owner can further delegate the privilege to others by creating a similar credential and signing it.  The new credential includes the credential that is the basis for delegation in the new credential's parent element.  This recurses.  

Encoding these in ABAC is accomplished in two ways: 
 * the right to delegate is encoded in an ABAC credential
 * the rules for valid delagation (that the delegator must have the privilege and the right to delegate) is expressed in the AM policies.

An undelegated credential that can be delegated expands into ABAC statements of the form:

{{{
Issuer.privilege_Target <- Owner
Issuer.can_delegete_privilege_Target <- Owner
}}}

An

{{{
Issuer.privilege_Target <- Issuer.can_delegate