In Progress - please ignore

GENI-Compatible ABAC credentials

GENI is currently working toward making ABAC the primary authorization system for the GENI AM API. A first step in that direction is to use the ABAC prover library, ​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.

The workflow for an aggregate manager is that when it receives a request through the GENI AM API it will initialize an ABAC prover with its current policy (to allow dynamic policy changes), import the information in the GENI Credentials in the request, and ask the prover if the caller has the privileges needed to make the call. Specifically, the AM will check the same privilege strings it currently checks but using the ABAC prover to get the allowed/denied answers.

That leaves two problems to address:

• Encoding the policy for import into the ABAC prover
• Importing the information from GENI credentials into the ABAC prover

Because we are encoding the current static, global GENI policies, storing and importing them is relatively easy. We can encode the generic parts of the policy into a configuration file on the aggregate manager once. For dynamic parts of the policy - specializing the generic policy for a specific target - a short code stub will be inserted into the AM. This is consistent with using an ​RT0 lite template. Note that none of these policy encodings need to be exchanged, so they can be stored in legacy libabac formats.

Importing the information in a GENI credential is accomplished by modifying libabac's credential input routines to recognize GENI credentials and convert them into valid ABAC rules. The ABAC rules need not be exchanged; they are only used in generating the answer to the authorization question. Our plan is to use existing GENI credential formats in the short term, but to add new formats in the long term. The new formats will support the full expressiveness of ABAC and can be used to store policies in more human readable formats as well as to pass more expressive ABAC information around in the future.

GENI components issuing GENI credentials and making requests using them will continue to pass the same credentials around, and require no changes. Parties making authorization decisions based on GENI credentials will add code provided by ISI to interface to the ABAC prover and rely on it to check access. This will add speaks-for to GENI.

The rest of this document discussed the semantics of GENI credentials including delegation and the "speaks-for" semantics, explains how those will be encoded into ABAC logic, and discusses the dynamic policy insertion. Readers will want to read farther the more they are interested in ABAC.

GENI Privilege Credentials

A GENI privilege credential encodes a set of statements of the form "The issuer of this credential (a principal) gives the owner of it (a principal) these privileges (strings) with respect to the target (a principal)." The privilege strings are defined with respect to the GENI APIs. For each of the privileges, a boolean is given and is true if the privilege can be passed to others.

The issuer is the principal that signed the credential. The target and owner are given explicitly as X.509 certificates. We can identify each of these principals by their public key from the X.509 certificates. In the short term that binding is stable. In the long term the ABAC policy can be take changing keys into account.

When the credential is delegated, the credential assigning the delegatable privilege (the base credential) is included in a new credential signed by the owner of the base credential. The owner of the base credential is the issuer of the new credential. The new credential assigns privileges to an new owner. The new credential is valid if the base one is, if the delegated rights are marked delegatable, and the expiration time of the new credential is no longer than the base. This recurses.

GENI Privilege Credentials and "Speaks-for"

The "speaks-for" privilege is intended to be used as follows. A user wishes to use a hosted 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.

This differs from delegation in two ways:

• Credential issuers need not issue delegatable privileges
• A tool need not receive and manipulate all the delegated credentials

"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 privilege credentials.

implement a credential format compatible with existing 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 ​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 GENI identity.

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's decision to allow Owner to exercize privilege on Target is expressed in ABAC as asking the prover if Owner has the AM.privilege(Target) attribute. For each Issuer that the AM trusts to authorize privilege(Target) the AM's policy includes the rule:

AM.privilege(Target) <- Issuer.privilege(Target)

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

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

Each AM will include this line in its policy:

Issuer.privilege(Target) <- Issuer.can_delegate_privilege(Target).privilege(Target)

That says that AM will treat a statement from a delegator as a statement from the issuer with respect to privilege on target.

When converting a delegated credential into ABAC, both the credential itself and the credential in the parent element are imported using the rules above. This recurses.

This can be expressed in ​RT0 lite

"Speaks-For" and Delegation

Existing GENI credentials support delegation of privileges. Each privilege in a credential 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.

One can imagine a system where a user gets only delegatable resources from Slice Authorities, AMs and other resource controllers and delegates them to tools for use. This has two major drawbacks:

• Resource controllers must issue delegatable resources or force users to share identity with tools
• Asking a tool to summarize the data about all resouces a user holds at a given source would require delegating rights to access each resource individually, which is cumbersome

The solution that GENI is adopting is a "speaks-for" privilege. A credential bestowing that privilege from a user to a tool (a principal with a GID) allows the tool to act as the user. As with all privileges, it has an expiration, so this is not a complete aliasing. "Speaks-for" is independent of delegation, and by default GENI resource controllers will support it.

Expressing GENI privileges with speaks-for in ABAC

Here we describe the ABAC rules that describe the GENI policy as it stands. This section assumes one knows the ABAC definitions, and the ​RT0 lite encoding of RT1 single parameter attributes. (In a nutshell, an RT0 lite encoding of the RT1 credential Principal.Attribute(parameter) is Principal.attribute_parameter).

For 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 ​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?"

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).

Aggregate Managers do not issue these credentials themselves, so there are rules about who they believe. 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:

AM.privilege(Target) <- Issuer.privilege(Target)

Issuers, such as Slice Authorities and Clearinghoses, issue credentials to users. Because GENI allows all privileges to be passed around by "speaks-for" the ABAC for issuing a privilege to a user (P) looks like:

Issuer.privilege(Target) <- Issuer.speaks_for(P)
Issuer.speaks_for(P) <- P
Issuer.speaks_for(P) <- P.speaks_for(P)

The 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.

When a user (P) issues a speaks-for credential for a tool (T), that credential encodes the following ABAC rule:

P.speaks_for(P) <- T

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:

AM.resolve(Target) <- Issuer.resolve(Target)
Issuer.resolve(Target) <- Issuer.speaks_for(P)
Issuer.speaks_for(P) <- P
Issuer.speaks_for(P) <- P.speaks_for(P)
P.speaks_for(P) <- T

When AM asks its prover if T can proceed (is in AM.resolve(Target), the proof chain looks like:

AM.resolve(Target) <- Issuer.resolve(Target) <- Issuer.speaks_for(P) <- P.speaks_for(P) <- T

Adding Delegation

Each privilege in a GENI privilege credential includes a flag indicating it is delegatable. For each privilege they assign to user P, such a credential adds the following two rules:

Issuer.privilege(Target) <- Issuer.can_delegate_privilege(Target).privilege(Target)
Issuer.can_delegate_privilege(T) <- Issuer.speaks_for(P)

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.