Version 15 (modified by 12 years ago) (diff) | ,
---|
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. While there are other issues to consider, for example improving libabac portability, this document does not address them.
Current GENI credentials allow one principal to grant privileges to other principals. If the original granting principal allows it, privileges can be further delegated.
The "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.
This differs from delegation in three ways:
- Semantically a tool operating under "speaks-for" authority is exercising the user's authority under close supervision. The user is taking the action through the tool and the user is responsible for the actions. A delegated privilege is exercised independently by the receipient of that delegation. The user who has been delegated authority is responsible for its use, not the delegator.
- Credential issuers need not issue delegatable privileges
- 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.)
Speaks-for and Delegation
As 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.
The 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?).
It 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.
The ABAC prover will support either choice. The current state of affairs is that a tool operating under speaks-for cannot delegate privileges.
ABAC authorization in GENI
When 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 GENI AM API it will
- Initialize an ABAC prover with its current policy (the prover is initialized for each request to allow dynamic policy changes),
- Import the information from the GENI Credentials in the request
- 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.
There are 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 RT1-lite template. Note that none of these policy encodings need to be exchanged, so they can be stored in legacy libabac formats. We describe the contents of those policies below.
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 privilege credentials in the short term, but to add new GENI credential types (the format is extensible) 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
This section describes the content and use of GENI privilege credentials. These are the only kinds of GENI credentials in use, but the presence of a type field indicates that other formats can be defined. We expect to do so in later phases.
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. For example, a slice authority (issuer) can grant the resolve privilege to a user (owner) on a given slice (target).
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 current semantics, When the credential is delegated, the credential assigning the delegatable privilege, called 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 Policy in ABAC
Here we describe the ABAC rules that describe the GENI policy as it stands. The policy and credential formats are somewhat entwined, and we cannot speak of one completely without the other. This section assumes one knows the ABAC definitions, and the RT1-lite encoding of RT1 single parameter attributes. (In a nutshell, an RT1-lite encoding of the RT1 credential Principal.Attribute(parameter) is Principal.attribute_parameter).
We give the ABAC as RT1, and explain how the RT1-lite conversion will happen later.
Unlike the description above, we first describe how to encode a policy that supports "speaks-for" and then add delegation. Speaks for is actually the simpler rule.
Expressing GENI privileges with speaks-for in ABAC
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 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).
Aggregate 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:
AM.privilege(Target, Principal) <- Issuer.privilege(Target, Principal)
There is one of those rules for each privilege it understands
AM.resolve(Target, Principal) <- Issuer.resolve(Target, Principal) AM.info(Target, Principal) <- Issuer.info(Target, Principal)
The Principal argument to the privilege attribute allows requesters to differentiate between a principal acting for themself and a tool acting for another principal. If a tool T submits a request asserting that it speaks for principal P the AM would ask the ABAC prover to prove that AM.privilege(Target, P) is true of principal T. If that attribute is provable about T the speaks for is in effect.
Issuers, 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.
Because 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:
(1) Issuer.privilege(Target, P) <- Issuer.speaks_for(P) (2) Issuer.speaks_for(P) <- P (3) Issuer.speaks_for(P) <- Issuer.TrustedTool & P.speaks_for(P)
These ABAC statements mean: (1) The Issuer says that anyone that speaks for P can exercise the privilege as P (the second parameter). (2) The Issuer says P speaks for itself. (3) The Issuer says that anyone that the Issuer believes is a trusted tool and that 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.
When a user (P) issues a speaks-for credential for a tool (T), that credential is translated into ABAC as:
P.speaks_for(P) <- T
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. "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.
To be concrete: if (in GENI terms)
- AM trusts Issuer about
resolve
onTarget
- Issuer has handed P a GENI privilege credential assigning
resolve
onTarget
- P has issued a "speaks-for" credential to tool T
- The issuer trusts tool T
- T makes a request including both credentials
AM has the following ABAC rules in its prover:
AM.resolve(Target) <- Issuer.resolve(Target) /* from static policy and RT1 lite expansion */ Issuer.resolve(Target) <- Issuer.speaks_for(P) /* From Issuer GENI privilege credential */ Issuer.speaks_for(P) <- P /* From Issuer GENI privilege credential */ Issuer.speaks_for(P) <- P.speaks_for(P) /* From Issuer GENI privilege credential */ P.speaks_for(P) <- T /* From User GENI privilege credential (speaks_for) */ Issuer.TrustedTool <- T /* Separate TrustedTool ABAC credential */
When AM asks its prover if T can proceed (if T 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, P) <- Issuer.can_delegate_privilege(Target, P).privilege(Target, P) Issuer.can_delegate_privilege(Target, P) <- P
The second line restricts delegation to the principal to whom the credential was issued, as current formats imply. If 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:
Issuer.can_delegate_privilege(Target) <- P.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.
RT1-lite templates for AMs
One of the things RT1-lite must do is to generate RT0 statements for new parameterizations of the RT1 statements. In this system, an RT0 statement of the form
AM.privilege_Target <- Issuer.privilege_Target
Needs to be created and added to the ABAC context the first time each (privilege, Target) pair is encountered by AM. This is the code stub mentioned in the introduction. Similar stubs will be needed by other resource controllers that call the ABAC prover.
If existing RT1-lite templates are available, we will use them.
Conclusions
This has described the implementation strategy for GENI privilege credentials using existing credential formats and implementing "speaks-for." Most of the development is focused on accepting existing GENI privilege credentials and translating them into ABAC. We have also laid out the ABAC that reflects the existing GENI authorization strategy at AMs.