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 Federation is the act of trusting and sharing identity information about users between systems. As described below, other systems can share information about its users with GENI via Identity Provider integration, while GENI shares information about its users through OpenID .

Identity Provider Integration

In order for GENI to authenticate a user, it needs an identity provider to release "Research and Scholarship" (R&S) attributes to GENI. Many academic institutions belong to the InCommon Identity federation and of these, many provide the R&S attributes. Such institutions automatically gain access to GENI. Other systems need to set up an identity provider that provides the appropriate attributes.

If they do, GENI will include their Identity Provider (IdP) in its list of trusted IdP's. GENI in turn will provide its Identity Service Provider (SP) meta-data to your IdP so that your IdP recognizes GENI's SP. From there, a user from an outside institution can create a GENI account using single sign-on authentication to the GENI Portal via their IdP.

A number of systems, e.g. NTUA, Cafe, UPMC, SAVI, Chameleon have shared their identity information with GENI in this manner, allowing them to log into GENI services and use GENI resources.

More information about GENI's approach to Identity Provider Integration can be found at

OpenID Integration

A number of systems or services rely on GENI to provide identity attributes to it: they do not have their own IdP but wish to rely on GENI for identity information.

GENI implements an OpenID Identity Provider. It will share standard identity attributes (e.g. user nickname, email) with services implementing the OpenID Relying Party protocol. Other attributes (e.g project membership) may be provided by GENI on request.

Only users who have already authenticated to the GENI Portal via the GENI or a federated IdP can share their GENI identity attributes via OpenID.

GENI is currently integrated via OpenID with the GENI Experimental Engine (GEE), the NYU WiTest Lab, LabWiki and Rutgers ORBIT Lab.

More information about GENI's approach to OpenID Integration can be found at

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.

More details about the GENI Aggregate Manager API can be found at and,


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.

More information about the GENI Federation (Clearinghouse) API can be found at

Data Plane Federation

L2 Connectivity

In order to establish L2 connectivity to GENI resources, the federating resources must be connected to a L2 network provider that connects to GENI. AL2S is a prime example, but other regional networks (CENIC, SOX, NOX, e.g.) satisfy this need as well. Connecting to a GENI topology requires allocating the correct VLAN tag associated with the 'last hop' to the resource and provisioning a circuit for that VLAN. This may require manual circuit management and switch configuration. Automating this process is down by implementing support for stitching, described below.


The GENI stitching protocol allows resources to be connected at L2 in a programmatic, automated fashion. The resource owner must stand up an Aggregate Manager (AM) that manages not only the computation/storage resources but the network resources as well, managing the allocation of VLAN tags and switch configuration. Once this is in place, the aggregate manager can be listed as in the GENI Stitching Computation Service (SCS) which allows computation of hop-by-hop topologies at L2. Topologies, including the new resources, can then be allocated using stitching tools to create an end-to-end L2 connected topology.

More information about GENI stitching can be found at

Last modified 7 years ago Last modified on 02/05/16 09:36:23

Attachments (1)

Download all attachments as: .zip