Authorization in GENI

Session leaders

Steve Schwab, Cobham
Ted Faber, ISI
Tom Mitchell, BBN


Tues 2:30 - 4:30 pm


This meeting will seek agreement on an approach to authorization in GENI. A proposed way forward will be presented along with possible alternatives, followed by open discussion.

GENI requires an authorization solution that will allow architectural components (Clearinghouse, Aggregates) to determine the privileges of an experimenter. Experimenters can be granted privileges based on institutional affiliation, project role or membership attributes, for instance. Aggregates are expected to have local policies regarding resource access and use.

There are two proposed solutions in use by current control framework projects, credentials and attributes. Credentials bind a set of roles or privileges with an experimenter and a slice. Attributes denote individual properties of an experimenter and are grouped to determine privileges. There are pros and cons to both approaches. Stakeholders will discuss both approaches and reach consensus on a way forward for authorization in GENI.


ABAC should be added to the GENI AM API as a means of authorization. Aggregates should accept ABAC-style attribute assertions to enable richer authorization policies than are possible with current GENI credentials. A proposed set of access rules will be presented and a prototype GENI-ABAC integration will be described.


Introduction - Tom Mitchell (5 mins)
Authorization proposal - Steve Schwab/Ted Faber (30 mins)
Break (30 mins)
Invited discussion - Jeff Chase (10 mins)
Invited discussion - Rob Ricci (10 mins)
Open discussion - All (25 mins)
Session wrap-up - Tom Mitchell (10 mins)

Community Agreement from the Meeting

  • ABAC should be added to the GENI AM API as an alternative means of authorization
    • Does not replace existing credentials
    • Supports gaining experience with ABAC
  • An existing aggregate should be ABAC-enabled
    • Aggregates are not required to add ABAC support
    • Supports gaining experience with ABAC
    • ProtoGENI AM is the likely first target
    • Experience and proposed next steps to be reported at GEC11
  • Limit the ABAC 'experiment' to 1 year
    • Either select it or reject it within that time frame

Next Steps

  • ISI: Integrate ABAC assertion handling into ProtoGENI AM (w/GPO support)
  • ISI: Implement existing access rules as ABAC assertions
  • ISI: Issue ABAC assertions for existing users
  • ISI: Explore richer assertions and policy rules within ProtoGENI code base
  • ISI: Report results by GEC11

Selected Discussion Points

Steve Schwab
  • Current authorization
    • Current authorization mechanism uses SFA credentials: signed XML documents
    • Currently: Roles map to privileges map to operations. Messy
    • In practice, only the slice authorities make authorization decisions: Aggregates simply accept slice credentials issued by trusted slice authorities.
  • Authorization goals
    • Support many policies: different aggregates, resources, groups
    • Support many users and groups of users
    • Uniform language for authorization policy
    • Support auditing
  • ABAC is flexible, with a well founded logic and formulism
  • ABAC supports logging with proofs of why access was granted or denied
  • ABAC attributes could map 1:1 to existing credentials. Ted has illustrated this.
  • Could instead have ABAC attributes map 1:1 to operations.
  • No need for global agreement on attributes: only need to agree at both the spot they are generated and the spot they are consumed
  • ISI / TIED project have described encoding existing AM API rules as ABAC assertions, and how to integrate ABAC into the GENI AM API (see the meeting background reading).
  • Plan
    • Try within ProtoGENI and discuss at GEC11
    • Build reference policies for AMs
    • Adapt current rules to start, then simplify
    • Support both credentials for now
    • Will invite others to try it prior to GEC11
  • Tools for manipulated assertions & policies are needed; ISI demonstrated some at demo night
Jeff Chase
  • ABAC is consistent with basic GENI security agreements
  • Beauty of ABAC is that anyone can be a trust anchor: AMs just need to trust them
  • External identity providers can be sources of attributes
  • Note that resource allocation decisions may involve limits on quantities, etc
    • ABAC may not be sufficient
  • ABAC supports delegating privileges, which is important
  • May need parametrized attributes - like a limited RT1
    • the creator of an object may have special rights
  • There's a difference between delegating to someone (I'm no longer responsible) and allowing someone to speak for me (eg a proxy service)
    • May need a SpeaksFor attribute
Rob Ricci
  • Existing mechanism in use for about a year successfully
  • Existing mechanism is based on capabilities NOT role like ABAC.
    • Be clear
  • Policies should be explicit, not in code as currently
  • Avoid complex logic that people won't understand
  • Avoid negotiation of what attributes to pass
  • Provide useful feedback on failed access, maybe indicating next step
  • Trust boundaries: Can we bound what slices authorities can act on? Is RT1 needed for this?
  • Maximize tool support
    • Existing ISI ABAC library uses poorly supported certificate format, which isn't good
    • Simple clients should be able to parse attributes without full inference engine
  • Limit parallel authorization schemes to 1 year
  • Existing implementation doesn't handle dates well. RT1 does more
  • Improving returns from AM API would help with explaining failures
  • Existing library exists to read and manipulate assertions from multiple languages
  • Avoid complex issues like negotiation
  • Standard error codes would be nice
  • Want to be able to say things like "members of group X can allocate up to Y amount of resource Z"
    • RT1 would support that
  • Ted says: RT1 expected this summer
  • GENI is not a research program. Build simple infrastructure.
  • SAML vs X509 assertions?
    • SAML would appear to offer better tool support, but...
    • Need to find an existing SAML implementation
  • How should we support numeric computations?
  • Will need common language of basic assertions so we can be consistent
  • Be nice to users and admins: not too complex, provide good tools

Background reading

Proposed ABAC Rules for GENI Authorization:

Sec 2 summarizes current GENI credentials
Sec 4 introduces ABAC
Sec 5 a prototype ABAC implementation of GENI authorization

ABAC integration with the GENI AM API discussion:
ProtoGENI Credentials:
ProtoGENI Authentication:

Further reading

GEC 8 ABAC Tutorial Slides:
GEC 8 ABAC Tutorial Slides:
ABAC Project:

Last modified 13 years ago Last modified on 04/12/11 15:58:57

Attachments (3)