Version 5 (modified by, 8 years ago) (diff)


Strategies and Approaches for Federating with GENI

GENI provides a variety of methods by which external resources, systems and testbeds can federate with GENI. By 'federate', we mean to be able to share resources, services or information with GENI in a mutually trusted manner.

There are typically three broad categories of federation with GENI:

  • Identity Federation: Sharing identity information between GENI and another system
  • Control Plane Federation: Allowing GENI users access to your services, or your users access to GENI services
  • Data Plane Federation: Allowing Layer 2 network connection between resources allocated on GENI and resources allocated on your testbed.

This page describes different approaches supported in GENI for these different kinds of federation. The following figure summarizes these different kinds of federation and key approaches:

Figure for Summarizing Approaches for GENI Federation

Identity Federation

Identity Provider Integration

Federating with GENI Identity NTUA, CFE, UPMC, SAVI, Chameleon Release Research and Scholarship (R&S) Attributes from your IDP We give SP metadata to you, incoporate in your SAML meta-data as an SP you recognize

Then your people can log into GENI

OpenID Integration

You: OpenID Relying Party Us: OpenID Identity Provider Provide standard identity attributes (nickname, email) plus other attributes on request (e.g. project membership)

Set of tokens to ask for additional attributes Send data about me to other services

Already logged into Portal thorugh SHIB

Authenticated already through SHIB We hand off AUTHN Info

Control Plane Federation

GENI provides two Control Plane API's: the Aggregate Manager (AM) API allowing allocation of resources to sliced topologies for authenticated/authorized users, and the Clearinghouse (or Federation) API which creates trusted credentials to support the AM API along with advertisement registry services.

Aggregate Manager

In order to federate a set of resources (racks, e.g.) with GENI, the owner of these resources must implement an Aggregate Manager service that presents these resources and allows allocation of these resources. Once this AM is in place, the AM must trust the GENI clearinghouse by including the GENI Clearinghouse CA certificate in its bundle of trusted roots. Once these steps are completed, GENI users will be able to share your resources through your aggregate manager.


Federating with GENI does not require implementing a Clearinghouse nor interacting with the GENI Clearinghouse (Aggregates do not speak to Clearinghouses). That said, the Clearinghouse maintains a registry of recognized and vetted services and having your Aggregate Manager listed in the GENI Clearinghouse Service Registry is a way of publicizing that you are making your Aggregate Manager (and thus your resources) available to GENI users.

Data Plane Federation

L2 connection AL2S or other GENI L2 Network Provider Stitching AM managing network resource (VLAN allocation and provisioning)

L2 Connectivity


Attachments (1)

Download all attachments as: .zip